By Asanka Abeysinghe
VP, Solutions Architecture, WSO2
Most enterprises today have created a set of services, incorporated some legacy applications and databases, and on top of that created applications like web apps, mobile apps, and consumer-based applications. While this might be a typical scenario, enterprises often struggle with the resultant complications; therefore, today most organizations are in the process of shifting to a clean service-oriented architecture (SOA).
Architects have a greater challenge now with the concept of microservices becoming increasingly popular within SOA. But it's not a totally new concept. Even a few years ago, some enterprises had started to adopt this concept by spinning up a new environment for each service they wrote instead of sharing existing ones, thus enabling easy maintenance as there were no dependencies between services. Likewise, different development teams were using similar concepts as well.
In a very realistic sense, microservices is somewhat of a link between the technologies of two generations. The concept has been explained in different ways. Tight coupling was prevalent in the pre-SOA, or the Platform 1.0 era, which resulted in complications. The progression to Platform 2.0 saw more loose coupling because there were larger services; it included messaging, object orientation, the emergence of traditional SOA, and eventdriven architecture (EDA). The concept of distributing computing moved to the next level in what's referred to as Platform 3.0, which essentially contains the good features that came from Platform 2.0 and the incorporation of next-generation middleware. With the evolution in technology, microservice architecture (MSA) offers complete decoupling thus ensuring agility of delivery and flexibility of deployment.
It's not a completely alien concept though; it essentially pulls all the SOA best practices and then links them with modern application delivery and tooling, such as Docker and Kubernetes, and technology like Puppet or Chef to carry out automation.
That aside, a common misconception among architects about microservices is that it's about the size. However, when they design services they should instead consider how they would scope out their services and eventually make it a proper set of microservices.
Figure 01
Figure 1 depicts a typical MSA reference architecture. While most architects are keen on the inner architecture where you would write the microservices and deploy them, there's an outer architecture too that would need to be considered. This involves the way in which services get invoked, how the services are governed, how the services communicate with each other, and the rest of the deployment would come beneath these.
The inner architecture refers to microservices and the runtime for hosting microservices, i.e. the services component; the outer architecture is about additional middleware runtime(s) that extend the microservices into an enterprise architecture pattern.
MSA has many features that focus on various aspects; however, the following (as explained in a blog by James Lewis and Martin Fowler)1 could be identified as a key set of features that MSA should contain.
Componentization as services - this basically refers to dividing large services into small sets of services and theoretically they should communicate with each other independently without going through a common messaging layer.
Organize around business capabilities - over time the concept of building systems across business units has changed to meet today's requirements; now organizations operate as pods with each business unit using their own technical capabilities to build applications to provide functionality to their own consumers.
Smart endpoints and dumb pipes - this concept somewhat leans towards having a pointto-point connection; however, given the potential complications that could arise with connecting services to each other, a messaging layer can be used to address the same requirements.
Decentralized governance - this refers to the need to breakaway from having a common set of practices and policies to solve varied and rapidly changing business requirements, and to meet specific business stakeholder demands.
Decentralized data management - this concept will use different types of data stores to store different data instead of having a centralized one. However, a challenge from the business side is the need to have common data sets as well as models even if they individually store different data stores.
Infrastructure automation - this is a key feature in microservice architecture and refers to how you build solutions from dev, then take it to the testing phase and eventually into production, and then how you could quickly spin up new instances based on runtime features.
Design for failure - this is not a new concept and you can write code using this crash only concept. Yet, from a platform perspective, you would need some key features such as devops-friendliness to spin up new instances in case one instance goes down. Moreover, data and analytics is important as well to be able to monitor, predict, and take necessary actions.
Evolutionary design - this concept focuses on avoidance of building a heavy solution and rather using a concept like an MVP (most viable product) and improving this in an iterative manner.
With the above key MSA features in place, the next step would be to ascertain what's required in terms of middleware.
With regard to componentization as a service, the middleware should basically provide a high performance functionality as well as support various types of service standards that comply with RESTful service implementation standards like JAX-RS. It also needs to be lean and use minimum resources in your infrastructure thus providing the necessary lightweight and high-performance runtime to dynamically deploy the services.
For organizing around business capabilities, the middleware should include a platform for business units to build services and expose those capabilities. While these small groups would have the freedom to build applications, the middleware should also provide some sort of governance as well as some standards to write applications on top of the platform.
Figure 2 illustrates a sample reference architecture that can be referred to as a platform for digital transformation. The diagram shows different middleware capabilities, such as API, integration, analytics, security, governance, etc. that have been provided as a platform and how the various business units utilize these. There's also the concept of multi-tenancy that's heavily utilized; each business unit will get a tenant and utilize it or some organizations may opt for a federated deployment where the same platform can be duplicated and run with different business units as well. However, what's important is that the platform will contain a set of standards that will be inherited by all and used in their respective deployments.
Figure 02
In order to provide a product to the end-user, an enterprise should use different types of technical capabilities, hence the middleware stack should offer a complete stack with endto-end capabilities as explained in Figure 3.
Figure 03
The enterprise would require different types of capabilities to carry out various tasks. From the source system of record to system of records, you would see all the storages that you store and data access capabilities built on top of that; you may also need data virtualization as there might be some non-compliances with the standards that you need as a data model from your APIs; lastly, you would have all the SOA-related components and the API would be the consumable unit of the service. On top of the services, you would have all the APIs and all the delivery channels and applications you write for your consumers. Thus, a business unit can create an application and then provide it if they have most of these capabilities in their middleware platform as it will enable them to easily write a service, build applications, and provide these to consumers. The devops and infrastructure-related components too would come across the different architecture layers that are shown in the diagram.
In the case of implementing smart endpoints and dumb pipes, the middleware should support the bus and broker architecture. Enterprise integration patterns would be useful too as apart from the microservices, you would need to connect your legacy systems, i.e. connecting the old world with the new world. Middleware capabilities such as an enterprise service bus (ESB) and a message broker still play a vital role to accommodate connectivity in MSA.
The concepts of API-driven and polyglot programming in Platform 3.0 will help to resolve issues related with decentralizing governance. Platform 3 is a revolutionary way to do development that many companies are trying to adjust to; in other words, it's a platform for IT growth and innovation built on mobile devices, cloud services, social technologies, big data analytics, and the internet of things. When an enterprise exposes everything as an API they also provide freedom to app developers to write applications. Even though these developers will use business functionalities via the API there is no risk as the APIs are properly secured and the usage of the APIs are governed as well.
On the other hand, to decentralize data management, the middleware should provide or support EDA; for instance, in case there are updates to data or a different set of data needs to be refreshed, an event-driven nature enables eventing that will push these events and make sure all sources that subscribed to the event will be updated and propagated to their system. That way data-related functional capabilities, such as transaction management and data security, can be implemented with the support of EDA.
In terms of infrastructure automation, the middleware platform would need to be devopsfriendly and support functionalities like automation testing, continuous integration, and containerization. It would also need to support devops automation like how devops scripts are carried out and how middleware supports scripting and distributed deployment. In terms of containerization and virtualization, you would spin up an instance and then communicate with each and every node, such as hashing and throttling, to ensure proper distributed deployment. The deployment should be able to support higher availability and scalability as well. Lean, independant runtime is key in case dependencies will not allow you to quickly spin up a new instance; what's required is the ability to quickly boot up the runtime and make it a part of the existing cluster that's running already.
As discussed earlier, big data analytics is important to ensure design for failure. To meet this requirement, the middleware platform should have a comprehensive data analytics solution and should be devops-friendly. Moreover, it should support an iterative architecture and implementation to maintain evolutionary design. To do this, the middleware should be pluggable, i.e. you should be able to plug component without affecting the runtime, and it has to be extensible where you can change the middleware based on your needs as well as those of your domain.
To meet all of these requirements, an enterprise would need a complete middleware stack that can support different types of platforms (Figure 4).
Figure 04
The middleware platform should be able to carry out all integration requirements and then service writing, API management, analytics, and security. It should also be able to support mobile and IoT needs as well as dashboard stores, and app development and management. Lastly, it should have the capability to integrate with various systems like legacy systems and Cloud-based systems as well.
Figure 05
Figure 5 maps WSO2's middleware capabilities with the MSA reference architecture explained earlier (refer to Figure 1). The above diagram illustrates how WSO2 has created some microservices as well as microservice-like architectures. For instance, WSO2 has a lightweight, fast runtime and annotation-based programming model, WSO2 Microservices Framework for Java, offering the best option to create microservices in Java with container-based deployment in mind. WSO2 Message Broker is used to do messaging and WSO2 Governance Registry is used for governance services of your APIs. To expose all these services as a service gateway, you can use WSO2 API Manager to take care of the API management component. For security and identity requirements you can use WSO2 Identity Server and capturing of data analytics can be carried out with WSO2 Data Analytics Server. In order to connect the old world with the new world, WSO2 also has a traditional enterprise service bus, WSO2 Enterprise Service Bus, which also supports technologies that come from Docker and Kubernetes as a container as a service and then Puppet for automation as well. It's further supported by WSO2 Gateway, an ultra high performance, lightweight and configuration driven message gateway based on standard gateway patterns.
To create a platform for innovation as well as rapid application development, an enterprise should build an API-driven architecture that's more consumer-driven. It can then utilize the infrastructure and dynamically add to the platform based on runtime events; these are not statically configured and everything works based on the runtime where the events will flow and then based on those events you can make decisions.
While an MSA is the way forward, enterprises would need to strike a balance by incorporating the good things in an existing architecture. It's important to not lose existing applications as well as some key SOA principles. Middleware capabilities like integration engines as well as tools that are being used, and distributed deployment with functional containers should be included in the architecture built with microservices.
For more details watch our on-demand webinar on A Pragmatic Approach to Microservice Architecture: The Role of Middleware.
For more details about our solutions or to discuss a specific requirement
