Microservices have become mainstream in building modern architectures. But how do you actually develop an effective microservices architecture? This post explains how to build an optimal microservices environment by adhering to the following five principles:
- Cultivate a Solid Foundation
- Begin With the API
- Ensure Separation of Concerns
- Production Approval Through Testing
- Automate Deployment and Everything Else
Principle 1: Great Microservices Architecture is Based on a Solid Foundation
No matter how great the architecture, if it isn’t based on a solid foundation, it won’t stand the test of time. Conway’s law states that “…organizations that design systems … are constrained to produce designs which are copies of the communication structures of these organizations…”
Before you can architect and develop a successful microservice environment, it is important that your organization and corporate culture can nurture and sustain a microservice environment.
We’ll come back to this at the end, once we’ve looked at how we want to design our microservices.
Principle 2: The API is King
Unless you’re running a single-person development shop, you’ll want to have an agreed-upon contract for each service. Actually, even with a single developer, having a specific set of determined inputs and outputs for each microservice will save you a lot of headaches in the long run.
Before the first line of code is typed, determine a strategy for developing and managing API documents. Once your strategy is in place, focus your efforts on developing and agreeing on an API for each microservice you want to develop. With an approved API for each microservice, you are ready to start development, and begin reaping the benefits of your upfront investment.
Principle 3: Separation of Concerns
Each microservice needs to have and own a single function or purpose. You’ve probably heard of separation of concerns, and microservices are prime examples for the application of that principle. Additionally, if your microservice is data-based, ensure that it owns that data, and exists as the sole access point for that data.
As additional requirements come to light, it can be very tempting to add an additional endpoint to your service that kind of does the same thing (but only kind of). Avoid this at all costs. Keep your microservices focused and pure, and you’ll avoid running into the nightmare of trying to remember which service handled that one obscure piece of functionality.
Principle 4: Test-Driven Approval
Back in the old days, when you were supporting a large monolithic application, you’d schedule your release weeks or months in advance, including an approval meeting which may or may not have included a thumbs up/thumbs down vote, or fists of five to convey approval or confidence in the new release.
With microservice architecture, that changes. You’re going to have a significant number of much smaller applications, and if you follow the same release process, you’ll be spending a whole lot more time in meetings.
Therefore, if you’re implementing test-driven development (TDD), writing comprehensive contract and integration tests as you develop each application, you’ll finish your service up with a full test suite which you can automate as part of your build pipeline. Use these tests as the basis for your production deployment approval process, rather than relying on the approval meetings of yore.
Principle 5: Automate, Automate, Automate
As developers and engineers, we’re all about writing code which can automate and simplify the lives of others. Yet, too often, we find ourselves trapped in a world with manual deployments, manual testing and manual approval processes and change management. Automating these processes when it comes to microservices is less a convenience and more of a necessity, especially as your code base and repertoire of microservices expands and matures.
Automate your build pipelines so that they trigger as soon as code is merged into the master branch. Automate your tests, static code analysis, security scans and any other process which you run your code through, and then on condition of all checks completing successfully, automate the deployment of the updated microservice into your environment. Automate it all!
Once your microservice is live, ensure that you have configured a means by which the service can be automatically configured as well. An automated configuration process has the added benefit of making it easier to both troubleshoot and remember where it was that you set that “obscure” property for that one microservice.
Conclusion: Back to the Foundation
At the start of this article, I mentioned Conway’s law, and said I’d come back to talking about what kind of organization you need in order to facilitate successful microservice development.
This is what your organization should look like: Each team should have a specific aspect of the business on which to focus, and be assigned development of functionality within that area. Determine the interfaces between teams right up front. The key is to encourage active and engaging communication and collaboration between the teams. Doing so will help to avoid broken dependencies and help to ensure that everyone remains focused.
Empower teams with the ability to make their own decisions and own their services. Common sense may dictate some basic guidelines, but empowering teams is a lot like automating processes, and it’ll both fuel innovation and make your life easier.
Now, with all that said, you probably don’t have the luxury of building a brand new development department from the ground up. More likely, you’re going to be trying to implement changes to a group of folks who are used to doing things in a different way.
Just as with microservices, or any software project for that matter, focus on incremental improvements. Determine an aspect of the culture or the organization that you’d like to change, determine how to implement that change, how to measure success, and test it out. When you achieve success, pick another incremental change to work on, and when you fail, try a different approach or a different aspect of the business to improve.
About the Author
Mike Mackrory is a Global citizen who has settled down in the Pacific Northwest – for now. By day he works as a Senior Engineer on a Quality Engineering team and by night he writes, consults on several web based projects and runs a marginally successful eBay sticker business.
5 Patterns for Better Microservices Architecture is published by the Sumo Logic DevOps Community. If you’d like to learn more or contribute, visit devops.sumologic.com. Also, be sure to check out Sumo Logic Developers for free tools and code that will enable you to monitor and troubleshoot applications from code to production.
