Microservices and containers are perhaps the greatest potential change in how IT organizations deliver and run software services since the arrival of virtual machines. Such a change brings with it lots of interest and enthusiasm, and inevitably much hype and bandwagon-jumping, too.
But, amid all the noise, let’s not forget that it’s early days yet—not just for the technologies, but especially for the processes and practices around microservices and containers. Pretty much everything in this space is either still waiting to be invented or needs a lot of fine-tuning.
Given the incredibly rapid pace of change in this area, it’s essential you have a clear understanding of the capabilities of the technologies and experience level of your teams before making any implementation decisions. Bottom line: Doing research is absolutely not the same thing as going for full-scale adoption. Production is never a good arena for R&D.
Here are six important questions organizations should ask before moving beyond research:
1. What is your business need? Perhaps the most fundamental question you and your company need to answer before deciding to adopt microservices or containers is whether there is a real business problem that needs to be solved—one that cannot be solved satisfactorily with your existing approaches or technologies. Microservices and containers are new, evolving fast, and still not very well understood, all of which represent risks that need to be balanced by some concrete benefits for your teams and organization.
2. Do you have the engineering know-how? If you are convinced that microservices and/or containers do indeed promise to solve a problem that you can’t address in other ways, make sure you have access to expert platform engineering resources, because you will need them. This issue extends well beyond the fact that APIs and frameworks are pretty much brand new. Getting a container-based platform up and running in production means solving many “adjacent” problems that the current frameworks cannot address, such as optimizing networks, deciding on storage strategies, handling backups and failover, dealing with security, and so on.
3. Are you willing to learn as you go? At present, there are many more questions around production-ready microservices and containers than there are answers. Even if you have the right engineering expertise to handle the challenges, you should be prepared for a multi-year period of ongoing experimentation and learning.
At least some of the APIs and frameworks you will choose will undergo significant, backwards-incompatible changes or even fall by the wayside entirely. You will also need to rip and replace others that turn out not to be suitable or mature enough for your scenario. Finally, there’s the matter of best practices for everything from operational procedures to app delivery patterns; be prepared to develop these yourself.
4. Do microservices equal containers? There is a common perception that microservices and containers are basically two sides of the same coin, and that you need one to do the other.
Containers indeed tend to nudge you in the direction of making your deliverables smaller, and so tend to move you away from monolithic applications. However, it’s perfectly possible to move toward a microservices architecture without using containers as an underlying runtime technology.
5. How well does the new technology handle dependencies? A microservice is often defined as an independently deployable unit, one that can start up successfully without requiring all kinds of other components to be available. However, in the vast majority of cases, “No microservice is an island.” A single service may boot up and respond to certain API calls on its own, but in order to handle scenarios that are actually useful to the user, you typically need multiple services to be available and talking to each other.
If you want to implement microservices using containers, the good news is that a number of frameworks provide increasing levels of support. Still, the state of the art in terms of runtime/microservice dependency management, and especially visualization, is way behind what we have for build-time dependencies. This is an area you will likely need to tackle yourself, at the very least by augmenting the capabilities of existing tools.
6. Do you know what’s involved in getting apps into production in a container environment? A big reason why Docker containers are so popular is that the “Hello world” experience is truly great. Getting a sample application (in the language of your choice) running in a container is a very simple, rewarding experience. In addition, taking the next steps of adding some tweaks is easy to get right.
However, getting applications running in production in a container environment is a totally different thing, especially if you’re moving toward microservices. Not only is building your own PaaS (effectively what you’ll be doing) a hard engineering challenge, you’ll need to address a bunch of process-related issues, too.
In sum, microservices and containers should definitely be on your research agenda. However, before you decide to push ahead with any adoption, make sure you understand the challenges and are aware of the investment in time and resources. View everything from this perspective: Do you have a genuine business need that justifies the effort and risk?
