Docker Containers: Challenges of Modern Application Delivery
In this article, we will be discussing some of the many challenges which present themselves as organizations adopt microservices, docker, containers, and continuous delivery practices. This blog post isn’t aimed at solving all your problems, but to give you an idea of where you will likely encounter friction and how you might go about solving these issues in an organic fashion that aligns with your organization.
When to use Docker Containers
You’ll find hordes of articles about leveraging docker containers and microservice patterns, so I won’t repeat what’s already been said in at least 20 other places. Something that is often overlooked is that Docker allows us to package almost any application that was built in the past 10 years (longer, if you’re in for a challenge) and deliver that application using a vast landscape of mature tooling. You can choose from Kubernetes, Marathon DC/OS, Docker Swarm, and now Netflix’s Titus. This is the secret sauce behind Docker, it allows for an opinionated approach to delivering software. This software can be microservices or legacy services, each has its own sets of challenges. If you can master and automate the tooling for packaging your applications, you will be in a great position for delivering the next generation of services for your business, microservices.
What really matters? Pipelines.
As an engineer, I will take every opportunity to experiment with the newest and most popular tools, languages, frameworks, and platforms available. This is understandable as tools such as Bamboo or Mercurial can certainly feel outdated or burdened with what seems like excessive manual intervention in order to properly automate. Be careful here, adopting additional new technologies is adding complexity for the entire organization as they begin to assimilate the new process and ecosystem.
Carefully evaluate existing technologies in your organizations and if you can find ways to fully automate using these solutions you should. Nevertheless, you will likely be forced into upgrading some older technologies or outright replacement for others. If setting up or defining your build process requires any sort of manual intervention it will not be sustainable. A small team of engineers (10) can produce several new microservices a month. There is no time for GUIs in this brave new world. Adopting containers and microservices requires all components in the software build and delivery life cycle to be decorated via configuration and actions to be triggered through an API or from an event.
I cannot overstate how important it is to automate your build and delivery pipeline. In many cases you’ll find yourself partially automated at first but will quickly recognize the patterns to fully realize end-to-end automation. Don’t let this work fall to the wayside. Constantly improve and standardize your pipeline or you will feel the consequences later. This typically will manifest itself in bottlenecks and increased complexity when your engineers begin to rapidly author new microservice applications. There is something else which can be non-trivial to automate for organizations, let’s dive into it.
Originally published at https://www.instana.com.
