Do You Need Microservices to Make Containers Worthwhile?
Earlier this week, I had breakfast with a colleague of mine from Rancher. Rancher is a great "orchestrator" for Docker containers. I have recommended and used them in production environments.
Containers - one of the hottest technologies in the last year - is a much more efficient form of virtualization than traditional "hardware" virtualization (think VMWare or Xen), while providing a superior application distribution model.
The challenge is that while the native Docker tools are pretty good for managing individual servers with containers, managing more than a few containers, let alone across more than a few servers, becomes impossibly complex.
Orchestrators "orchestrate" the containers and their running in a complex environment.
Over breakfast, we had a great discussion about how critical microservices are. While containers enable microservices in a way that was extremely difficult before, are microservices necessary to gain the benefits of containers? If you prefer, must I have a microservices strategy to make my containers strategy worthwhile or even viable? Or can I gain benefit from containers and good orchestration even if I do not separate my services?
My contention is twofold:
- Containers have significant benefits for any organization, whether "fat" (multiprocess) or "thin" (micro) containers.
- Solid orchestration is necessary as soon as you move beyond a few containers or 1-2 servers. I would argue that even with one server, implement an orchestrator.
Whether or not commercial orchestration and the support contracts that go with it are worthwhile at smaller scale depends on the complexity and skills of the organization and the features of open-source vs. commercial products.
However, enabling microservices is just one of containerization's benefits. Others include:
- Clean, even pristine, distribution
- Identical development/testing/production environments
- Separation between immutable code and mutable data
- Rapid startup and shutdown
- Much more efficient use of computing resources: disk, cpu, memory
- Better development and operations culture
However, before diving into containerizing an environment - or any major change - it is important to answer two related questions:
- Why am I doing this? Is it just "61% of successful general storm hills, so we will storm a hill?" (thanks @swardley) Or is there a fundamental problem that needs to be solved? If so, how does it rank for your company compared to other problems?
- Do I have a strategy for this? You cannot just flip a switch and be on containers instead of bare-metal or VMs. You need a strategy that takes into account your technology, performance requirements, processes and especially culture.
Culture is an enormous part. How much change can your people absorb at once? Which group that is crucial for change is overloaded? What other projects will be impacted and how?
Summary
Like any major technology change, you need to know why you are doing it and have a strategy for what it will look like and how you will execute it. "61% of tech shops do it" is a good way to fall flat.
Do you have both good reasons and good strategy? Ask us to help you determine what changes will have the biggest impact and how to make them succeed.