After 1 year of establishing a microservice architecture, we’ve collected 4 useful mantras that can help you make decisions during your migration.
These mantras reflect experiences we’ve made on our journey. I gave a presentation once about this topic that you can find on Slideshare. This articles focuses on the mantras themselves.
Leaving a monolith system shouldn’t be done in one big but in many small steps. Each of them should end in a release. One approach is to accept the monolith to stay around for a while, but not adding new functionality to it anymore. You could see it as a feature freeze in your old code base. As projects usually roll, you’ll have to add a new piece of functionality at some point though.
That’s when our mantra helped us. Just put that exact feature into a new service. Having this very clearly scoped set of logic inside your new system helps you understand its mechanics. With each feature you’ll ship using this approach you’ll learn - without having to radically change everything.
Don’t reinvent the wheel. Really. Instead, build your system architecture on a strong fundament of established technologies and standards. In the case of Microservices a great example is the usage of JSON. When we checked for best practices on how to structure JSON on an API, we quickly realized that most providers cooked their own soup. This requires any client to build specific clients for each vendor, again and again (some offer SDKs, of course). But this doesn’t have to be.
Great standards like JSON API or GraphQL give you a great set of functionality that you can easily reuse. At Blinkist we decided to go with HTTP and JSON API for all our Microservice communication, internal and external. That allowed us to build our own small Microservice Client component that’s being used by all consumers of services - lean and straight forward to use. All networking complexity and response interpretation is handled inside the component. The developers don’t need to learn all these details again but can instead focus on their core business.
Software that nobody uses doesn’t help anyone. Neither does a refactoring for the pure fact of refactoring generate value for a business. It might reduce certain risks of failure, but that’s nothing we can really foresee. So instead of focusing on refactoring, focus on new functionality that comes with a certain effect to our business success.
Don’t get me wrong, sometimes refactoring must happen. But why not combining it and make it fruitful. Focus and build something new, and refactor something old while doing that. This helps you to keep your refactoring effective. E.g., instead of refactoring the whole outdated “payment system” you go for a specific new thing the Marketing people always asked you to build. Think about the architectural change that’s necessary for that and start planning your new feature. Spice up your planning with refactoring needs that’ll bring you closer to your new architecture and you’ll make everyone happy.
Leverage the tools of a specific vendor when they can help you grow quickly. Don’t be afraid of locking yourself in too much — just be smart and build your architecture in such a way that lets you move out again if it becomes relevant.
One grand example is Heroku (the PAAS provider). We’ve been running our whole business on their platform for more than 3 years, and they scaled with us. Once we decided to move out, it’s been a rather simple task. Our apps were all built in a very decoupled manner, and we’ve had an easy time migrating them over to AWS Elastic Container Service. Heroku educated us a lot to use everything as a service: databases, caches etc. We’re using a specific provider for each service and never hosted something ourselves. If you’re interested in our migration, here’s another slide deck I’ve presented at one of the AWS Meetups in Berlin in 2016.
References
Big ideas in small packages — How microservices helped us to scale our vision