Production Ready Microservices In Action
practical guide for cloud native Microservice development
We have re-engineered multiple product from Monolithic to Microservice . This blog gives you an overview of how we transformed/migrated from monolithic to Microservice based architecture at Equinix.
Monolithic application was developed using Java and was packaged as WAR files and deployed on Tomcat application server. Successful applications have the inherent habit of growing over time and would surface as a monster monolithic application, the result is an extremely complex application.
Time to migrate for Microservice based architecture when application is simply too large for any single developer to understand it fully, increase in #P1 after every release, hard to maintain, support team head count is more than the development team.
Splitting the Monolithic
Domain models, road to re-architecture
“Domain-Driven Design” by Eric Evans was the big influence on Microservice architectures. This is ostensibly a technique to decompose a large problem space into domains.
This is one of the important activity in this journey. Prepare functionality matrix to list down all the current functionalities and associated package/class file. Organize business capabilities which are copy of your organization structure.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvyn Conway, 1967
Design API endpoints behavior by describing them in common ubiquitous language that stakeholders of the project can understand. Domain-driven design or API-contract-first approach for defining a contract for each Microservice.
Tackling the Architecture Challenges
Architecture is an evolving model of your organization priorities
Any application rewrite will have architecture and engineering goals. Adapting Microservice architecture should address the below engineering and architecture goals
Domain (Private) API’s: Domain API’s are Microservice endpoints. Microservice endpoints are domain functionalities which might not be directly exposed to customer channels.
Experience (Public) API’s : Applications will have multiple experience channels like Mobile, Portal, Bot and API’s. Demands with respect to given channel will be different, to embrace innovation in each channel needs different API contract. Experience APIs will be created by orchestrating one or more Microservices.
API First Approach
Swagger based domain model design
Domain-Driven Design (DDD) helps the team to create a service contract. Model between the business and IT stakeholders that the team can use to communicate with the business requirements, data entities, and process models. The model is modular, extensible and easy to maintain as the design reflects the business model.
Swagger is a powerful open source framework backed by a large ecosystem of tools that helps you design and document domain models for the given service which include input, output and error parameter. Same can be shared as an API document and specification.
Technology Agility
Choosing the right technology
The next big challenge is to select the right technology to implement Microservice based architecture. Developers don’t need to share infrastructure, they can implement each service in a technology stack suitable to the complexity of the problem however to start this architecture style limiting to few technology stacks will help the company to reduce time to market.
Second, standardization has always been a mantra of IT organizations as a way to reduce costs and increase agility. Choose a programming language for service development and create end-to-end lightweight opinionated software framework which enforces the Twelve-Factor App standards. So that the team can get started with minimum fuss and focus more on business logic in Microservice based development.
NodeJS or SpringBoot for Java will be an ideal fit for Microservice based application development.
Spring Boot makes it easy to create stand-alone, production-grade Java and Spring based Applications.
Node.JS is an extremely lightweight open-source platform that’s driven by a passionate community. It is rich with ever-expanding modules contributed by enthusiasts and has a vibrant online community. Modular architecture goes nicely hand in hand with Microservice.
Container
DevOps revolution
In application development, there are two different type of environments: developer environment where developers write the code and deployment environment where operation team manages the application. Moving code between these two environments will lead to technical errors, lengthy time delays, and miscommunication.
Docker containers enabled us to build the ship and run each Microservice code in different containers. It is easy to configure and provisioning the Microservices stack in any environment is one click away.
Automating DevOps cumbersome manual routine task in operation is key for Microservice based application deployment. Agile development techniques encouraged developers to create tools to automate many of the cumbersome manual routine task in operations, referred by many as the DevOps revolution
This brought development teams and IT operations closer together using advanced tools like Puppet, Chef, Kubernetes and Docker.
21st Century Architecture
Agility, Efficiency and Resiliency
Selecting right architecture pattern and service collaboration techniques is an another important aspect of this journey.
Pattern #1 : Micro-Service with REST Endpoint Based Collaboration
Highly distributed and scalable. Complex orchestration & interaction . Deployment pipeline requires much more planning. Over a period of time, it’s hard to manage. In this pattern, Microservices will communicate each other if needed.
Pattern #2 : Microservice with Event-Based Collaboration
Use events to implement eventually consistent business transactions that span multiple services. The event queue is used to orchestrate the Microservices based on events defined for each API contract request.
Pattern #3 : Microservice with Orchestration Layer
The orchestration is used to orchestrate the Microservices based on workflow defined for each API contract request. Orchestrators are excellent at handling the requests in a generic way, establishing a set of rules that allow fully customizable API contract for each channel-like portal, mobile and API.
Avoid Pattern#1, Pattern#2 and #3 are equally good; it’s deepens based on nature of your product requirement. Based on our experience option #3 will be an ideal fit for large scale product development. Also, we have stared exploring “Microservice based architecture 2.0 (Feature-Based Development -FBD)” for our product developments. We will share more details soon.
However, our experience with the integration or orchestration of different Microservices is that it is considerably complex, not only in terms of custom mediation logic, which must be as complex as the end customer API contract demands with respect to a given channel, but also at the level of transactional control and correlation, even parallelism and performance.
If the right set of tools is not given in the Microservices world, developers will look elsewhere.
Security is Not An After Thought
Keep It Simple and Secure (KISS)
One of the important goals, when we build system end to end architecture, is stateless. Maintaining identity and access management throughout a sea of independent services will be tricky.
The traditional monolithic structure that may have a single security portal, Microservices pose many problems. Should each service have its own independent security firewall? How should identity be distributed between Microservices and throughout my entire system?
JSON Web Tokens to achieve the end goal of creating a distributed authentication mechanism for Microservices. Self-contained, standardized and easy to replicate.
Monitoring
Critical Component of the Control System
If the right set of tools is not given for MicroService monitoring, there is a high chance entire initiative will be in jeopardy. Few monitoring principles,
Monitor containers
onitor what’s inside the container
Alert on service and container performance
Monitor APIs endpoints
End to End correlation ID stretching for the given request
Leveraging below telemetry techniques will allow you to establish more effective monitoring as you make your way towards Microservices
The first of these, APM (Application Performance Management), consists of a stream of events that can be used by tools outside the cloud to keep tabs on how well your application is performing. Pinpoint is an open source APM tool for large-scale distributed systems written in Java
The second, stream of events and data that makes sense for business
which you can use for your own analytics and reporting
Third, health and system logs which are provided by your platform
Finally, application log with end to end correlation id stitching and performance metric on each method level for the given request
Teams
Self organized pizza teams, it’s about people not technology
How an architecture style will influence the restructuring the development team.
organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations
— M. Conway
Influence of Conway’s law in software development? Your architecture reflects team structure. Organizations are now organized cross-functional teams built around domains rather than structured around technology layers. For example, domain team includes Business analysts, UX, Developer, DBA and IT operations.
In future articles, we’ll discuss more details about 12 factors standards for Microservice and Microservice architecture 2.0. Stay tuned.
“I am an employee of Equinix. The opinions expressed here are my own and do not necessarily reflect the opinions of Equinix”
