Microservices Architecture — It Takes A Platform — Eureka!
As I enter deeper into the world of microservices, I do so on a quest of understanding. This article is part 3 in an ongoing series: 1) Microservices: A Journey of Understanding, 2) Microservices: Early Thoughts Before That First Step.
In the last two days, I experienced a breakthrough while reading Microservices: Flexible Software Architecture by Eberhard Wolff. I really like this book — it took me a bit, but I really do. The first two parts of the book goes over the motivations and basics of microservices along with what, why, and why not. These two sections give a good baseline of what we are talking about and it gives a fairly honest view of the downsides, risks, and why you should not use microservices.
The only problems I had with the first two parts of this book was the high level of repetition, and the regularly missing comma. The repetition, I am certain, is there to help people learn — the missing commas only served to remind me of: Eats, Shoots & Leaves. I really should read that book again. It is a favorite of mine.
It was in the third part of the book titled “Implementing Microservices” when I could not put it down. I found myself murmuring, “yes! yes!” People began staring at me, but I carried on. In was in chapter 7 where I found the clarity that I have been seeking. It was the place where I found my Eureka!
Microservices Architecture Platform Requirements
It is absolutely necessary for you, as the architect of a microservices system, to set forth fundamental requirements for any services placed into your environment. These are requirements which the teams in your organization must fulfill in order to place their service into production.
A bare minimum must include logging, monitoring, and deployment. But you can, and should, go further and specify other infrastructure requirements:
- Any data stores must be incorporated into data backup and disaster recovery plans.
- Service discovery and load balancing practices to enable the entire ecosystem to be discoverable.
- Security and resilience requirements.
- If provided, a common messaging and eventing system can be made available for ease of development.
- How is configuration handled: Deployed with each service, or provided through a platform configuration system?
The need to have a baseline set of requirements is simple avoidance of chaos. If you left all of these fundamental decisions down to 10 different microservices teams, you would have 8 different ways to locate services, 7 different logging systems, and 3 different monitoring systems with minimal coverage of failures.
Obviously I make these numbers up, but the point is that if you are responsible for the overall organization, then you need to ensure that you have defined the platform for microservice development. You establish the rules in which microservices teams connect to the environment, and you provide tools and pieces of infrastructure to actualize the platform.
Starting the Platform
Now that I am starting to look at my job as providing a platform within which teams will work, I am starting to think about what are the things that I want to provide — rules and tools. The rules will be the requirements we decide upon from the above. The tools will be a technical implementation of some portion of the rules in a chosen platform language. These tools will ensure that teams can instantly begin working without having to write code for these requirements.
This is the list of things that I am considering. These are not all things that would appear from day one, and their implementations are likely to grow and expand over time.
Logging — This would definitely be a built-in part of the platform infrastructure. It would likely consist of Splunk along with technical documentation on the format of messages and configuration of forwarders. Format specifications should include identification of the microservice, time, and severity. There should also be very specific security logging requirements including formatting. Every microservice call (both inbound and outbound) must be recorded; a shared infrastructure can perform this, but if direct connections are utilized the microservices themselves must participate in the logging.
Monitoring — There would be strong rules around monitoring and the platform infrastructure would, by necessity, provide the monitoring system. A core requirement for monitoring will include traceability of service requests through the environment (aka message flow). The message flows through the system are an important monitoring datapoint — especially correlations between related messages where ratios remain consistent for a healthy system.
CI/CD — As a standard and a tool, this is a fundamental requirement. You must have automation on builds, testing, and ultimately deployment. Without the tooling in place, there is no way that producing new microservices is easy. A microservices platform is failing if producing new microservices is not easy.
Service Location — I have been around the block plenty of times to know that service location may not be a big thing up front, but that can change suddenly. As the number and diversity of services continues to grow a service locator will prove invaluable. If the microservices cloud is going to be highly elastic (new instances coming online/going offline dynamically), a service locator may be necessary from day one.
Load Balancing — If we decide to have load balancing be done client-side, then a part of the platform will be providing a technical specification for how to do load balancing, and an official implementation in a chosen platform language will be provided. In the platform implementation, this may be baked together as part of the service locator. (Look at me violating single purpose without writing a single line of code!)
Configuration Services — If we decide to use configuration services as a part of our infrastructure, I would expect us to include one as a part of the platform infrastructure. We would ideally not want different teams to setup their own configuration service and end up with 30 different solutions. I have to figure out where I sit with the concept of immutable server before I would agree to provide this as a part of the platform.
Messaging Infrastructure — If we determine that message passing (request/response, publish/subscribe, etc.) are important, I could easily see us hosting one as a core platform service. This would enable teams to use messaging easily without having to setup their own infrastructure. This might not preclude a team from setting up and using their own if the need arises. However, if your system is going to utilize a great number of events, having a unified messaging platform would be ideal.
Messaging Standards — Each microservice should not reinvent the wheel in terms of how messaging is done. They can have flexibility, but standards around using messages, events, and REST API endpoints would be best in order to provide a framework which teams can use to begin their work.
Authentication and Authorization — Every system needs it. Internal users. External users. Etc. There needs to be a system to provide it, and there needs to be agreed upon standards on how to validate authentication and how to enforce authorization. Authorization should be handled at the individual microservice.
Key Management System — Microservices will need access to secret keys and passwords. Placing these in the code or in traditional configuration systems is asking for trouble in the long run. Key management systems abound today, and the platform should provide one to the microservices ecosystem.
Testing — Standards around unit and integration testing is a must. CI/CD pipelines should be considered incomplete without some level of testing to fail builds dynamically. Teams do not want to push faulty code into production, and the platform should help them.
Documentation — The interface for a microservice is tantamount to a contract. If you know and understand the interface to a service, then your ability to consume it is high. When the interface is undocumented, you leave others the difficult task of intuiting and troubleshooting their way to being able to use your service. (I recently had the unfortunate experience of needing to work with Scala Lift code… the Lift documentation is abysmal with just a class structure as documentation.) I have a dream that the services would include an API for retrieving the documentation for the service-in-production; this ensures that the documentation lives with the code and not in an external documentation system.
Tools for Microservices in Diverse Languages — The Sidecar
One of my early struggles understanding this requirement is how it goes against the idea that a team can choose any language they desire for their microservice. The sidecar is the answer to this problem — the team will write their service in their chosen language, and they will run a sidecar process in the platform language that provides this base set of functionality to it. How this looks exactly I have not fully formalized, but it makes sense to me.
My only concern is how bulky that sidecar becomes. Two existing frameworks I have discovered through some amount of searching have been JVM based — including Netflix’s own. The idea of running a JVM for services which are not JVM based feels wrong. The JVM has always felt heavy to me, and it feels like having a friend drive an 18-wheeler to the grocery store for me because I want to ride my bike — we do need somewhere to put all of those groceries, right? Nevertheless, the sidecar concept is a completely viable option.
More Coming!
I am still finishing this particular book, and I will continue to post on more insights gathered. I will probably also update this article as I think about more details for the platform. I am also looking at putting together a post of just the resources that I find most useful for microservices. Lastly, these are my next three books which you will likely read about here:
- Building Microservices — This book is referenced by Martin Fowler and others as a key book in the movement.
- Production-Ready Microservices — This book has been touted as one which dives directly into the topic of this article — the support a production platform should have to enable microservices.
- Domain Driven Design — Everybody in microservices is talking about this book. The Object Thinking book talked about this book. If everybody is talking about this book, it is highly likely one to ready.
