Yesterday, I attended Container Summit: The Future of Containers in the Enterprise, which occurred in cooperation with the Interop conference. Thanks to the great people at Joyent, it was a day packed with fantastic presentations and more than a few takeaways.
My über takeaway from the day is that it's getting harder and harder to talk about containers without also talking about microservices. There were examples of containers in use for a variety of use cases, but it was their particular suitability for use with microservices that came through loud and clear.
In addition to that uber takeaway, here were my top five takeaways from the summit:
- Microservices are the next big tech wave
- Microservices create complexity
- Developer experience and developer velocity are key success factors
- There likely won't be one winner for container orchestration
- Running containers on bare metal isn't just for the brave
And check below for my favorite one-liner from the event :)
Microservices are the next big tech wave
We learned that 90% of enterprises see containers and microservices as the key to their modernization efforts. This supports the assertion of Container Solutions' Jamie Dobson, who states that we've entered the fourth major wave of application innovation spanning the past few decades. Jamie sees the waves beginning with Object-Oriented Applications, followed by Online Systems, Distributed Systems, and now Microservices. While significant benefits are to be gained from microservices, many will struggle to ride this newest wave since many of the supporting practices and technologies have not moved beyond "Wave 3" yet. In particular, the need for new monitoring approaches are needed, such as semantic monitoring, that move away from periodic, outside-in monitoring, to event-based, inside-out monitoring. Management is another key element that will need to evolve to support Wave 4.
Next, Jane Arc provided a fascinating explanation of how that works at Uber, with distributed, service-oriented teams that operate to meet centrally-provided expectations for service performance, but not centrally-provided mandates on how to achieve them or what to use. Per Jane, the typical, uber (no pun intended) system architecture design managed by a central enterprise architecture group becomes impossible in Wave 4, as the distributed growth and change inherent in the system makes it impossible to keep it updated. Instead, they constantly perform architectural analysis via end-to-end flow analysis to ensure services interact properly for user scenarios. Lastly, how to manage global security practices across inter-connected microservices and how to handle stateful storage were two other key areas where new practices will evolve.
Microservices create complexity
Multiple speakers discussed the tradeoff you make when adopting a microservices approach. In exchange for greater control provided by smaller units of change and the ability to deploy changes in one area of a system without affecting the rest of the system, you accept greater system-wide and organizational complexity that comes from managing a (much) larger number of services. Victor Gajendran, of NeoPraxis, shared his experiences, highlighting the complexities created for deploying and managing microservices, orchestrating them, managing service discovery, scaling automatically, and managing security. He found that containers, combined with a plan for coordination and management, made handling the increased complexity possible. He emphasized the need for the right tooling to understand dependency mappings, cascading service health impacts, data ownership, and container lifecycle management.
Developer experience and velocity are key success factors
"A great developer experience is necessary for developers to do the right thing," Adam Eivy, of Disney, said. Whether developers are more utilitarian than the average person isn't important, but no one wants to be "helped" with tools, practices, etc., that aren't actually helpful. This is where containers and the Docker syntax have struck the right chord, making it easier than ever before for developers to self-serve their environments. At a previous conference, one of the speakers from the Ops leadership side of the house said, "There are three tsunamis going on inside our [Fortune 500] company right now. The number one wave is containers. Whether we wanted to or not, we couldn't stop it. Developers find it so useful, they're bringing it in and adopting it quickly." James Ford, of ADP, had a different experience. His platform team could see the potential benefits, but had to get others to see it. By demonstrating how containers create developer velocity and by linking that velocity to product velocity, he was able to convince developers to get through the learning curve and adopt containers. Adam Eivy took it a step further, promoting a Docker-based bootstrap process internally that ensures a new developer to the team can be fully installed and ready to be productive with three commands -
$ git clone ...,
$ cd ...,
$ ./init. His team's dev environments are ready in minutes, not after days of struggle.
There likely won't be one winner for container orchestration
Alex Williams, of The New Stack, shared his team's latest research on the state of the container ecosystem, which showed Kubernetes, Ansible, Mesos/Mesosphere, Amazon ECS, and Docker Swarm as the top options in users' plans for adopting container orchestration in the upcoming year. An entirely different approach to orchestration was presented by Casey Bisson, of Joyent, called the 'Autopilot' pattern. It is an alternative to master-based orchestration systems in which the responsibility of registering, configuring and managing a service's interactions with other services is managed within each service by the developers. The fact that there are many orchestration options in this evolving space isn't surprising. What was surprising was a statement made by multiple enterprise presenters during the day, as stated by James Ford, "I can't see any time in the future where we'll be committed to a single container platform. I expect we'll run multiple platforms."
Running containers on baremetal isn't just for the brave
It turns out it's not hard to do, either in the cloud or on-premises. Zach Dunn, of Optoro, and Cliff Pearson, of UC-Santa Cruz, shared their experiences running Joyent Triton on-prem. The performance improvements and cost savings achieved by avoiding the hypervisor were, in their words, "dramatic." In addition, the platform nature of Triton made it easy to provide self-service options, improving the developer experience within their organizations.
I'll close with my favorite line from the event, provided by Bryan Cantrill, of Joyent, who provided many great lines throughout the day. In describing the role of the Cloud Native Computing Foundation, he explained that the CNCF is not defining standards, because standards can sometimes be seen as a bad thing. "They're not standards - it's emerging, rigorous consensus...which may sound a lot like standards."
Check out the videos from the event once they're posted, which will be available on the Container Summit website.