This blog post is one in a series that will give you some insight into the full day training class (Microservices Solution Architectures) I will be teaching at the ITARC Austin on October 6th, 2016.
A better question may be “If I can’t/don’t change , am I going to create business value?” In my opinion, the greater number of changes you can make around the adoption of microservices the greater chance of success with the implementation.
In my opinion, the best chances for success will rely on the following:
1. Adopting a cloud-first development strategy
The ability to independently build, deploy and support microservices means your existing monolith may turn into dozens, if not hundreds, of vertical business capability slices. Scaling this idea in your datacenter is most likely not going to be successful – unless you have build your very own AWS or Azure from the ground up. In my experience, the cost alone to implement in a proprietary datacenter would be enough to steer away.
2. Implementing DevOps (or at least, continuous delivery)
How will you truly get the “speed to market” benefits purported by microservices if you can only push code to production every three to six months? The market moves very quickly, and the ability to deliver new and enhanced capabilities at a rapid pace will help differentiate your business.
3. Organizing around small independent teams
This has to do with dependencies and coupling. If a single large team owns all of the microservices/capabilities, there will inherently be dependencies between capabilities as well as deployments (think Conway’s Law). If you want to deliver enhancements to your shopping cart, but it’s dependent on (or is a dependency for) your user profile or payment system, your push to production may have to wait to make sure you don’t break other capabilities.
4. Adopting a more flexible SDLC
I almost put the word “agile” here, but that is an overused term. I don’t know a single engineer or architect that loves waterfall. Your microservices won’t love it either. As microservices are small and independent, so should your delivery process be. Is your business going to want to wait six months to review what you have done? What if they don’t like it?
5. Implementing a container strategy
Most likely, your microservices will need to be in containers. The speed and efficiency at which containers deploy and exist is far superior to virtual machines.. and chances are, you will need to share resources. What if your microservice needs to live on the same virtual machine as other entities? Now you have a dependency on the specifics of the environment. Alternatively, if a single microservice lives on a virtual machine, is it going to utilize the CPU, disk, memory efficiently?
6. Adopting domain-driven design patterns
Whether you are decomposing a monolith or working with a business capabilites map, the ability to decouple your functions from one another and create a bounded context around each one will make your microservices deploy quicker. Designing your microservices in such a way that they align with business capabilities allows for independent management, versioning, maintenance and enhancement.
7. Coming to terms with eventual consistency
Microservices are, by definition, vertical slices of capability that extend all the way to the data layer. However, this means that microservice A may have data that microservice B requires. Even if microservice B has the data, it may be stale as each service is not working on the same copy of data as they are independent. Designing your system in such a way that allows for user data to be eventually consistent breaks the need for hard requirements on things like dependencies and transactions.
8. Preparing for increased failover/monitoring/logging capabilities
How successful are you today in handling disaster recovery for your monolith? How easy is it to debug a problem in production? What happens to your performance at various peak hours? Any answers here would need to change considerably with microservices. You may need to monitor many capabilities/microservices at once. You may need to track a user flow through multiple services. A single microservice (or potentially multiples) may be at fault for performance issues. The infrastructure and process around support is vital.
The ability for organizations to change not only the technology but the design, process and understanding will be the most successful with microservices.