I’m personally really excited about the potential of microservices and containers, and typically recommend pretty emphatically that our users should research them. But I also add that doing research is absolutely not the same thing as deciding up front to go for full-scale adoption.Given the incredibly rapid pace of change in this area, it’s essential to develop a clear understanding of the capabilities of the technology in your environment before making any decisions: production is not usually a good arena for R&D.
Based on what we have learned from our users and partners that have been undertaking such research, our own experiences (we use containers quite a lot internally) and lessons from companies such a eBay and Google, here are six important criteria to bear in mind when deciding whether to move from research to adoption....
Genuine business need:
Microservices and containers are new, fast-moving and still not very well understood, all of which represents a risk factor that needs be weighed up by some concrete benefit for your teams and organization.I can’t say it better than Etsy’s former principal engineer Dan McKinley:
[Consider] how you would solve your immediate problem without adding anything new. First, posing this question should detect the situation where the “problem” is that someone really wants to use the technology. If that is the case, you should immediately abort.
Handling dependencies:
If you’re looking to implement microservices using containers, the available frameworks are providing increasing levels of support for this. Indeed, Kubernetes, Helios, Marathon, Fig a.k.a Docker Compose and similar other container orchestration tools have been created largely to handle container dependencies and links.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 (which, from what we’re seeing, is one of the reasons many of our users are interested in the new dependency management features coming in XL Deploy). This is an area you will likely need to tackle yourself, at the very least by augmenting the capabilities of exising tools.
One of the main reasons why particularly Docker comes up in many of our recent conversations, above and beyond the general buzz, is that the “hello world” experience is truly great. Getting a sample application in your language of choice running in a container is a very simple, rewarding experience, and even taking the next steps of adding some tweaks is easy to get right.
Beyond “hello world”
However, getting real applications running in production in a container enviroment is a totally different thing, especially if you’re moving towards microservices. Not only is building your own PaaS (which is effectively what you’ll be doing) a hard engineering challenge, there’s a whole bunch of process-related questions that need to be addressed as well.
No comments:
Post a Comment