Microservices Architecture for Enterprises

Recently, I attended a talk on Enterprise Microservices Architecture by Darren Smith, a general manager for Thoughtworks, Sydney.

The talk helped address questions I had about microservices architecture in large enterprises. Here’s a quick recap to help you as you explore the pros and cons for your team.

First and foremost, the message from Darren was that microservices architecture is not a new style of building large scale enterprise applications. Companies like Netflix and Amazon have implemented microservices architecture to deliver successful products over the last few years.

But is microservices architecture right for your organization? The answer is not a simple yes or no, but I will try to guide you to the answer using Darren’s talk as a guide.

Microservices architecture is a journey that will affect your organization across multiple dimensions - culturally, technically and operationally. Let’s consider a monolith application in a multinational enterprise that has matured over many years and dominated the market. From a software engineer or architect perspective, it is a good practice to simplify complex areas of your code base to make it more maintainable.

So what do you do when you encounter an insanely large Java class with many lines of code and an unfortunate method which contributes to 40% of the class? A natural (and sensible) thing to do is to engage some form of discussion with the team and come up with a strategy to break down the class into multiple smaller classes and/or methods. Now ask yourself why it was important to clean up the monolith Java class?

If your answer is simpler unit tests, easier to code review, change impact, then I suggest you to apply the same thought process to the monolith of services and modules that make up your product.

There are several reasons for breaking apart a monolith application into smaller, manageable services. If you are a business leader in your organization, following are probably some of your concerns:

• Entering into new markets
• Supporting innovation
• Creating greater alignment between business capabilities and systems
• Changing governance structures to better support rapid decision making
• Respond quickly to new market conditions
• Defend against market disruptors

As a CTO or a chief architect, it is your responsibility to evaluate different solutions that best address the concerns above and design a system which aligns with the organization’s vision. Here are some key areas to focus on when considering a microservices architecture:

• Dependency management among multiple services
• Size of end-to-end functional tests
• Detect failure fast, fail gracefully and recover fast
• Containers as build artifacts
• Component/Module reuse across organizational boundaries
• API contracts for services for public usage
• Monitoring various stages of deployment lifecycle
• Centralized architecture team vs decentralized architecture team
• Infrastructure automation

The role of an architect evolves with the adoption of microservices and entrusts him or her with challenging responsibilities that result in the formation of architectural governance. Architectural governance is one of the key factors for an organization trying embark on the microservices journey because without proper order, the process will quickly lead to micromanaging rather than microservices.

One of the greatest advantage of splitting up a monolith into multiple manageable services is enabling a small team to fully manage the lifecycle of its service - develop, test, and push to production. This means that the enterprise architect should no longer be burdened with the inner workings of an individual service but highly concerned with the interaction between services in the overall system. Furthermore, an architect should keep a close eye at the overall health of the system to ensure that every service produces metrics related to monitoring in a consistent manner.

Giving complete authority to a development team to pick the technology stack of their choice in building the services doesn’t imply that the architect no longer has any say into its implementation. In fact, the architects are highly encouraged to educate and influence the development teams. For example, an architect can suggest using a NoSQL database instead of a relational database considering the highly unstructured nature of the data the service has to deal with. For example, Netflix standardizes the use of JVM as a platform so that they can use standard libraries across services.

While one of the architect’s hand is busy collaborating with the development teams, the other is constantly working with "business" team in order to align the technical vision with business’ vision. This is an important trait for an architect because the system needs to be able to adapt to change in product’s vision or user feedback. Therefore, an architect needs to be always on top of latest trends, tools and frameworks in the industry and be ready to apply the right tools for the given job.

Darren talks about the concept of “deployment coupling” which highlights the fact that many monolithic systems and traditional enterprise architectures require changes to be synchronised across all systems in a single release to production. This in turn causes long running test cycles that never catch anything and a sense that no one can fail, because one system not hitting its deadline means everyone else is pushed out.

Deployment coupling can be avoided by using remote calls as a mechanism to integrate services. Microservices community recommends the use of REST over HTTP as opposed to other remote communication protocols like RPC or SOAP because non-HTTP based protocols tend either to tie you down to a specific platform or put restrictions on interoperability. By integrating services using HTTP based on user level contracts, development teams can avoid the trap of never-ending end-to-end testing phase and maintain a decent velocity.

Managing hundreds of services however complicates the operations for an organization. As an organization, you must ensure you have a solid DevOps infrastructure ready to tackle application monitoring and alerting. As I mentioned above, at a very minimum, an architect must standardize the way services emit logs so that the operations team can monitor the overall system health and be able to drill down into service-level monitoring if any further investigation is needed.

Lastly, every organization must strive to recruit, train and retain high quality technologists because it is critical that communication and collaboration between “micro teams” needs to be effective, technically stimulating and most of all fun!

I hope this defogs some of the concerns you had about microservices architecture in large enterprises. I encourage you to watch this very insightful video recording where Darren talks about these very concerns in greater detail. If you are looking for additional material on microservices architecture in general, check out Martin Fowler’s article or other microservices insight blogs on Thoughtworks website.