Pred ictin g T h e Fu tu re of De ve l o p me n t...Microservices Contrasting Architecture Patterns...

Predicting The Future of Development:

Microservices and Single-Page Applications A Discussion Of Two Architectural Styles That Mitigate Technology Shift and Promote Agility

A Keyhole Software White Paper

Table of Contents Table of Contents Introduction Single-Page Applications Microservices

Contrasting Architecture Patterns Microservices Explanation Features of a Microservices Architecture Configuration, Continuous Integration, and Deployment Agility Isn’t This Just SOA or Distributed Computing?

What’s The Catch? Eventually Consistent Immutability and Containerization Through DevOps

Application Security Shifting to Agility Getting Started With SPA or Microservices

Suggestions For Adoption Conclusion

About The Author About Keyhole Software

Related Services Snapshot White Paper Details

of 14 Tel 877-521-7769 https:/keyholesoftware.com

Copyright © 2016 Keyhole Software

https://keyholesoftware.com/

Predicting The Future of Development:

Microservices and Single-Page Applications A Discussion Of Two Architectural Styles That Mitigate Technology Shift and Promote Agility

A Keyhole Software White Paper

Introduction A common concern found in enterprise-level organizations is often asked by our clients: “How do we know that something new is not going to come along and make our current technology stack obsolete?” Or, to put it another way, “how long is our current technology stack going to last?” The short answers are that you don’t know, and we don’t know - at least not without a doubt. The long answer is don’t try to find answers to these questions, but to attempt to make the questions themselves obsolete. Do this by assuming that these changes are going to happen, and proactively put in place a decoupled system architecture that provides a smaller surface area of change for your applications for the future. There are two architectural styles that have become popular in the last few years that can help this proactivity come to pass, and in the process give you Agility. They are known as Single-Page Applications and Microservices. In this document, we will discuss these two architectural patterns including an overview of how they work, when best to consider them, and suggestions for a successful implementation of each approach.

Single-Page Applications Single-Page Applications (SPA) are built using an architectural approach that has gained popularity in recent years. SPAs specifically use HTML5 and JavaScript for dynamic HTML, essentially removing HTML generation completely from the server.




In this configuration, server-side logic provides a RESTful API layer into application logic and data access. A diagram illustrating this configuration follows.

Gallery 1: Single-Page Application Configuration Concept

HTML5 and JavaScript are specifications supported by the W3C consortium of vendors and the ECMA. This configuration is a robust standard that arguably supports the ultimate runtime environment: the browser. You would be hard-pressed to find a language and environment that is more supported and ubiquitous. Architecturally, SPAs decouple the user interface entirely from the server-side API. In a scenario of change, if the browser and HTML were to be replaced by some new technology, then the server-side API layer could serve this new user interface technology. Browser HTML rendering engines and JavaScript interpreters’ efficiencies have made SPA technology shine. There are also many JavaScript MV* frameworks that have filled in some of the language deficiencies found in JavaScript, namely modularity and namespace management. AngularJS, Backbone.js, and Ember are just a few. The bottom line is that for this approach you are committing to JavaScript as a full-blown development language. Therefore, JavaScript needs to be fully understood by each member of your development teams, just like any other language. Even though some of the MV* frameworks attempt to hide features of the language such as callbacks and asynchronous behavior, don’t let this be a crutch. You must empower your teams to understand JavaScript fully. A firm JavaScript knowledge minimizes the weight of the choice of a MV* framework, as then they will be able to move seamlessly between them.




Microservices Microservices is an architectural approach that shows promise. While there isn’t a standardized, formal specification, its distinctive style has been pinned down and implemented in a multitude of large-scale, mass consumer web applications and websites. Companies such as Netflix, Groupon, PayPal, Airbnb and other organizations that are implementing IoT (Internet Of Things) applications have all implemented a Microservices architecture. Many have pioneered design patterns and produced various support frameworks that help to manage and implement a Microservices architecture style. So, what is a Microservices architecture?

Contrasting Architecture Patterns First, as a frame of reference, let’s discuss what the contrast is to a Microservices architecture: a Macro or Monolithic application architecture. Monolithic-based architectures have been a common approach for the enterprise, where all application functionality is placed in a single deployable unit, such as a WAR/EAR or a solution package. The problem with this Monolithic architectural approach is that with applications of any size, changes made to any single feature of the application need to be tested extensively for unwanted side effects. Also, once in production, there is a dance that occurs between fixing defects and adding new features. What does a team do when in the midst of a development sprint production, defect remedies have to be applied? Sometimes they can be nestled into the current build, but sometimes new features have to be backed out so that production issues can make their way into the next production build. This is not efficient. Also, this approach can be error-prone. And as the application grows, deployment times of new and needed features get longer and longer, and the QA burden gets heavier and heavier. Also, the Monolithic application is built with a single technology, therefore introducing new technologies is an all-or-none proposition. For reference, a conceptual picture of a Monolithic architecture follows as “Gallery 2.” It depicts a very simple project management application that manages resources for projects.




Gallery 2: Monolithic Application Architecture Concept

Microservices Explanation In comparison, the Microservices style breaks up functionality into smaller runtime elements that can be tested and deployed separately using RESTful APIs with a lightweight, simple data transport protocol such as JSON. Application features and functions are broken up into smaller distributed pieces. A picture of the previous Monolithic application application broken up into a Microservices style of architecture follows, labeled “Gallery 3.”

Gallery 3: Microservices Application Architecture Concept




Features of a Microservices Architecture This style of architecture breaks up application function into smaller independent units that are accessed and discovered at runtime, whether over HTTP or a IP/Socket protocol using RESTful APIs. These services are made immutable through operating system containers (Docker) that allow these services, with all of their required software, to be packaged up in a nice image, moved to servers, and stopped, started, and discovered by other services. There’s no need to invent many common patterns in-house. Multiple companies that have had success with this style of architecture features have released patterns and frameworks that support Microservices architecture. Here is a quick description of some of these patterns: Service Registry - A service registry communicates when and if a service is available for use, and through a heartbeat mechanism, determines if a service is alive. Also, the registry contains the current location (server:port) of a deployed service. Service Discovery - Other services can discover the location port/dns of a dependant service, API Gateway - Servers as an API gateway for an application user interface into application services. Service calls can be aggregated here to serve specific user interface functions, or just passed through in order to avoid having to use CORS. Also, load balancing, user identity authentication and authorization can be applied here. Circuit Breaker - Since there could be many layers of service calls involved in an application, a failure of in one of them could cause a cascade of errors up the calling routes. The circuit break pattern captures failures and defines a threshold of failures within a specified time, and closes the circuit which immediately reports an error instead of attempting to repeatedly keep accessing the service. Companies such as Netflix have committed ready-to-use software to help implement these patterns. We recommend you check out https://netflix.github.io for a list of this software.

Configuration, Continuous Integration, and Deployment Continuous integration and deployment are other necessary features of Microservices that need to be addressed. A scheme to quickly roll out services with zero downtime exploits the smaller test and comprehension surface that Microservices supplies and provides agility and speed, but DevOps tools help to manage the complexity. Since one vision of this style of architecture is speed and scalability with lots of things quickly moving in and out of production, a mechanism to dynamically accept and communicate configuration propertie s at runtime is necessary. Simply providing or seeding properties and resource files during a build or by hand, and then starting a server will not work like it does in



https://netflix.github.io/


a Monolithic system. This is because Microservices will be changing much more frequently and could even be spread across multiple servers. Luckily, the industry has again supplied some ready-to-use solutions for this. Apache Zookeeper (https://zookeeper.apache.org/) is an open source distributed configuration mechanism that can be a solution for this. Along these same lines, application lifecycle management (ALM) software is absolutely necessary in order to aid in troubleshooting and monitoring services. The ELK (Elasticsearch, Logstash, and Kibana) stack is a popular solution to manage, filter, and view all the logging statements across a Microservices architecture.

Agility The process of gathering requirements have been made Agile with processes such as Scrum and Kanban, both which attempt to shorten development cycles. For example, the Scrum process time-boxes features and functions into a defined Sprint time period. At the end of the duration of the Sprint, the goal is production-ready software. This implies that it is tested and ready to go into production. In enterprise development of Monolithic applications, we have rarely, if ever, seen software go directly from a Sprint Demo directly into production. That said, we believe this is possible and should be the goal for Agility. A Monolithic architecture makes this goal extremely difficult, as the entire application has to be tested, and the issues that arise have to be dealt with. This is very hard to fit into a two- to four-week Sprint. In comparison, breaking up application logic and data access into smaller immutable, containerized services decreases the testing surface and shortens development time.

Isn’t This Just SOA or Distributed Computing? Sort of, but not really. Distributed computing technologies have been around for a long time. They are heavyweight protocols that require specific server implementations and expertise, and have complexity in use; think CORBA, EJBs, or WCF. Distributed computing frameworks are not super easy to use and require supporting server software. Service-Oriented Architecture (SOA) gained momentum starting in the mid-2000s, and while conceptually valid and similar to Microservices, its focus was on modeling coarse-grained services that had the ability to be reused across the enterprise. Lots of expensive middleware software (ESBs, Orchestration, Asset Repositories) make up the SOA ecosystem. Also, heavy human resource investment is required for analyzing the entire business to extract these services, then a rigid governance model to ensure implementation and usage, which produces another organization silo.



https://zookeeper.apache.org/


There are organizations that are having success with SOA, but our experience says that this came with a very heavy investment in software and human resources, and took a long time. Martin Fowler (Thoughtworks) makes a nice distinction between Microservices and SOA: SOA has smarts built into the wiring between services, while Microservices’ wiring or connectivity is dumb and the smarts are found in each service. 1

Microservices rely upon the ubiquitous HTTP/IP-based protocols and simple serialization/deserialization. So, most organizations are already outfitted and ready to rock.

What’s The Catch? Microservices are not a panacea for success. To avoid the giant-ball-of-mud problem, infrastructure and DevOps need to be put place in order for this to be Agile and manageable. Otherwise, you’ll have a bigger mess to deal with. Fortunately, mechanisms and processes to manage this have been pioneered and made available to us by high-profile companies like Netflix that give us an approach for successfully supporting a Microservices architecture. That said, skill in defining proper services and their sizes, along with implementing the required DevOps infrastructure, requires skilled resources and time. Current thought leaders in this space are debating if every application should start out as a Microservice, or whether smaller applications stay as a single deployed architecture and only larger size applications use a Microservices architecture. There is not any reason the Microservices infrastructure cannot be used to deploy an application’s traditional single server-side components along with more granular Microservices. There is likely a hybrid approach where certain services are reused by a traditional single deployment-based application. Technically, over time, more and more services will become available and can be reused. If an organization does not build all its application with Microservices, then available services won’t be produced. So, it may be better in the long run to just have all applications follow a Microservices architecture.

Eventually Consistent Another consideration is the distributed computing characteristic of eventual consistency, identified by the CAP theorem. This theorem states that it is impossible to create a system 2

with all three of the following points:

1. strong consistency (where all nodes see the same data at the same time),

1Fowler, Martin. (2014, March 24). Microservices. http://martinfowler.com/articles/microservices.html 2Gilbert, S., Lynch, N. (2002). Brewer's conjecture and the feasibility of consistent, available, partition-tolerant Web services. ACM SIGACT News 33(2): 51-59.



http://martinfowler.com/articles/microservices.html


2. guaranteed availability for data create, update, and delete operations, and 3. provides fault tolerance.

Applications with low latency and actual real-time requirements are not a good match for Microservices-based applications. An example application that might not be a good fit, or at least where critical functionality should not be distributed, would be a transaction-based financial application such as stock trading or some kind of real-time device control application. NoSQL applications that provide schema-less persistency that can be scaled across process Nodes also have to exist in an eventual consistency environment. This really does not mean a Microservices-based architecture cannot be used and you have to got back to a Monolithic application; the takeaway from this is the service boundary might be a little larger for a service implementation that requires full atomic transactions or very low latency. Considering that many enterprise applications are basically CRUD-based applications and require reliability and scalability, a Microservices architecture should not be a problem.

Immutability and Containerization Through DevOps There will be many more moving parts in a Microservices architecture. If Agility is the goal, then things could easily go the wrong way. So, services need to be easily deployed, started, stopped, and discovered, in other words immutable . If services had to be deployed in the 3

traditional software component (i.e. WAR/Solution) to a server environment with the assumption all the required and correct versions of software are in place (i.e. JVM, application server version, database drivers, etc.), maintaining and configuring this would probably derail Agility and introduce fragility. This is where Docker comes on the scene. Docker is a Linux/Unix and soon-to-be Windows containerization framework. Essentially, a Docker container is an image of all the resources and software for an application or service. These images can be managed and moved between environments by a continuous integration environment. 4

An image that is tested can easily and quickly be moved to a virtualized server and started on a Port. Using a self-discovering service registry, these services can be moved, started, and stopped without downtime. For more on Docker, I suggest that you read an introductory blog written by Keyhole Software Consultant Zach Gardner titled Docker: VMs, Code Migration, and SOA Solved .

3Butler-Cole, Ben (2013, June 10) Rethinking building on the cloud: Part 4: Immutable Servers. http://www.thoughtworks.com/insights/blog/rethinking-building-cloud-part-4-immutable-servers 4Gardner, Zach (2014, November 20). Docker: VMs, Code Migration, and SOA Solved. https://keyholesoftware.com/2014/11/20/docker-vms-code-migration-and-soa-solved/



https://keyholesoftware.com/2014/11/20/docker-vms-code-migration-and-soa-solved/


http://www.thoughtworks.com/insights/blog/rethinking-building-cloud-part-4-immutable-servers



Application Security We are not positive about this yet, and time will tell, but our instincts are that Single-Page Applications and Microservices may have less attack vectors for hackers than a traditional Monolithic application with server-side dynamic HTML. One of our reasons behind this opinion is that a lot of application vulnerabilities are removed due to the fact that dynamic HTML production is no longer on the server. Also, as application logic and data access can be spread across numerous servers and ports which can change, trying to hack into a port and determining what a service does for nefarious reasons is made much more difficult. Also, a container based OS typically will contain fewer things to access, than a full operating system.

Shifting to Agility Adopting the two architecture styles, Single-Page Applications and immutable, containerized Microservices, can help mitigate the ever-changing technology shifts in software development, tools, techniques, and frameworks. But also, if you are are using an agile process like Scrum where you are timeboxing development in an attempt to deliver “production-ready” software in short bursts of time, then these architectural styles are a necessity. With them, when a demo occurs of production-ready software, a button is pushed and it is really in production. This is as opposed to going into QA and Acceptance Testing for a long period of time.

Getting Started With SPA or Microservices Moving to an SPA architecture for your user interface-based web application is a fairly easy endeavor. Most likely your existing server-side application architecture can simply be modified so business logic and data access is served up as RESTful API layer. Then you can select a JavaScript-based MV* framework to implement your browser-based web application. You can keep application logic and data access in a single deployable component, but introduce an API gateway pattern and the service discovery pattern to completely decouple the use interface, containerize these elements using Docker. There are many choices and lots of experiences out there. Our experience helping companies adopt an SPA architecture has shown that any experienced developer can get up to speed quickly, they just have to fully embrace JavaScript. Also, don’t sweat too much over the selection of a JavaScript framework; they are always changing. The good news is once you get up-to-speed on JavaScript, moving between these frameworks is easy. But, make sure your developers get a good, pure JavaScript foundation first. Some opinionated frameworks hide some features of JavaScript, and while this gets folks up to speed, it stunts their ability to troubleshoot and move between frameworks.




Adopting an Microservices architecture has a much bigger impact on the organization given the fact that there are more moving parts. System Administration personnel will need to get on board with allowing teams to move containerized services in and out of service frequently and rapidly. Management and stakeholders may have to tolerate a little more expense and time to get the proper DevOps environment established in order to accommodate, govern, and manage a lot of services. Thought leaders of the Microservices front even suggest a shift in the traditional communications paths of an IT shop. This is referred to as the “Inverse Conway” which implies that the organization should partition staff to be responsible for a specific service from birth to grave , in contrast to the normal IT roles of responsibility and communication which 5

include siloed teams focused on gathering requirements, development, QA, DBA, and production. This doesn't mean that resources aren't moved around, but they are assigned to maintain and support specific services, including production support for those services. You can see how this organizational change could have a big impact.

Suggestions For Adoption We suggest that without going whole-hog into the Microservices architecture, try implementing and supporting some architecture-based services. For example, create an authentication service, or a role/privilege-based service, that your existing applications can be retrofitted to access. Almost every application requires this kind of functionality and you will be able to establish the required DevOps/continuous delivery environment without addressing the difficulty of end user requirements while tooling up the architecture. Or, as mentioned before, move the user interface of your applications to an SPA style. Another idea is to implement a Microservices environment for support code services. Many applications require presenting a list of support codes such as city, states, zip codes, or more domain-specific codes. While trivial, the process will provide easy-to-understand services that have much reuse potential, but more importantly allows your team to engage and establish the mutable containerized services deployed in a continuous way, before the explosion of Microservices that will result once this style is fully embraced.

Conclusion Enterprises are in a never-ending process of automating and analyzing processes in order to remain competitive and efficient. As this occurs every day in all areas of business and life, software development technology practices are evolving and improving at an accelerated rate. This white paper presented two technology areas, Single-Page Applications and Microservices, that can speed up the software development process and help eliminate the problem of

5Leroy, Jonny and Simons, Matt (2011, February 3). Dealing with Creaky Legacy Platforms. Originally published in December 2010 issue of the Cutter IT Journal. http://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy-platforms/



http://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy-platforms/


investing too many resources in building software solutions that become so large and complex that they cannot be changed or easily replaced. It is important to say that these approaches are not silver bullets; there never has been, and may never be such a technology. Because, it is more than technology, it’s people with a committed vision applying software craftsmanship. That said, there is the widespread adoption of HTML5/JavaScript, internet protocols, available cloud-based container technologies that allow computing resources to be easily managed and obtained, and some successful smart companies using these technologies and generously sharing them. If you are a typical enterprise looking to rewrite a Monolithic application or build a new application, then SPA and Microservices styles of architecture deserve a look.

About The Author

David Pitt is a Sr. Solutions Architect and Managing Partner of Keyhole Software with nearly 25 years IT experience. For the last fifteen years, David has helped corporate IT departments adopt object technology. Since 1999, he has been leading and mentoring development teams with software development utilizing Java (Java EE) and .NET (C#) based technologies. He is an author of numerous technical articles, and a co-author of a popular IBM WebSphere book that documents some of his architecture design patterns.

About Keyhole Software Keyhole Software is a Midwest-based software development and consulting firm with a team that loves technology. Our expert employee consultants excel as “change agents,” helping our clients to be successful with software technologies that bring competitive advantage. See some of our recent projects here. We frequently assist clients with custom application design, development, and modernization initiatives with Java, JavaScript/SPA, and .NET technologies. Keyhole was founded on the principle of delivering quality solutions through a talented technical team, and as such, knowledge transfer is important to us. To our clients, we offer various techniques to provide the most value: one-on-one or group mentoring, lab/lecture educational courses, and access to our knowledge transfer engine GrokOla.

Related Services Snapshot ● Technology Consulting – Expert Keyhole Consultants work with organizations to analyze

the current state of applications, recommend technical directions, and develop plans for modernization.



https://www.keyholesoftware.com/

https://keyholesoftware.com/projects/

https://keyholesoftware.com/services/education/

http://www.grokola.com/

http://keyholesoftware.com/services/technology-consulting/


● Application Development – Individual members or entire teams of Keyhole Software Consultants perform expert development services: application analysis, user interface design, development, testing, and enhancement of custom applications.

● Education – Instruction of a wide range of custom courses and technical mentoring programs for knowledge transfer to groups or individuals, including Introduction to Microservices, SPA Development With Full Stack JavaScript Using AngularJS and Node.js, JavaScript UI Development Using AngularJS or Backbone.js, and others.

White Paper Details

Cited References By Footnote 1. Fowler, Martin. (2014, March 24). Microservices.

http://martinfowler.com/articles/microservices.html 2. Gilbert, S., Lynch, N. (2002). ACM SIGACT News 33(2): 51-59. 3. Butler-Cole, Ben (2013, June 10) Rethinking building on the cloud: Part 4: Immutable

Servers. http://www.thoughtworks.com/insights/blog/rethinking-building-cloud-part-4-immutable-servers

4. Gardner, Zach (2014, November 20). Docker: VMs, Code Migration, and SOA Solved. https://keyholesoftware.com/2014/11/20/docker-vms-code-migration-and-soa-solved/

5. Leroy, Jonny and Simons, Matt (2011, February 3). Dealing with Creaky Legacy Platforms. http://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy-platforms/. Originally published in December 2010 issue of the Cutter IT Journal.

Other Relevant Resources ● Cockcroft, Adrian. (2015, June 17). State of the Art in Microservices.

http://www.infoq.com/presentations/microservices-comparison-evolution ● Richardson, Chris. (2014). A Pattern Language for Microservices.

http://microservices.io/patterns/index.html ● Apache Zookeeper. https://zookeeper.apache.org/ ● Elasticsearch, Logstash, and Kibana (ELK) stack. https://www.elastic.co/products ● Netflix Open Source Software Center. https://netflix.github.io/

Image Quick Links ● Gallery 1: Single-Page Application Configuration Concept ● Gallery 2: Monolithic Application Architecture Concept ● Gallery 3: Microservices Application Architecture Concept

Additional Contributors Dallas Monson, Luke Patterson

Edited By Lauren Fournier



http://keyholesoftware.com/services/application-development/

http://keyholesoftware.com/services/education/

https://keyholesoftware.com/services/education/full-stack-javascript-angular-node/

https://keyholesoftware.com/services/education/full-stack-javascript-angular-node/

http://keyholesoftware.com/services/education/ui-angular-course/

http://keyholesoftware.com/services/education/ui-backbone-course/

http://martinfowler.com/articles/microservices.html





http://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy-platforms/

http://www.infoq.com/presentations/microservices-comparison-evolution

http://microservices.io/patterns/index.html

https://zookeeper.apache.org/

https://www.elastic.co/products

https://netflix.github.io/


Pred ictin g T h e Fu tu re of De ve l o p me n t...Microservices Contrasting Architecture Patterns...

Documents

Transcript of Pred ictin g T h e Fu tu re of De ve l o p me n t...Microservices Contrasting Architecture Patterns...