A few weeks ago, I attended a talk about moving to microservices, in which the speakers, both of them DevOps program/delivery managers at a large online retailer, mentioned a rule they had. Tooling, they said, was not the answer to a Devops culture problem, but tools can be effective in slowing down or accelerating that very human effort.
This probably resonates well with anyone trying to drive technological change within an organization, and even more so with regards to cloud-native transformation in the enterprise, by which I mean the move to a microservices-based architecture and container-based infrastructure. It's the right tools, that support the right human expertise, that get the job done.
Take delivering code to production as an example. In the old world (i.e., before containers...), CI tools took code from a repo, delivered an artefact, and then initiated some testing (essentially, using a framework-specific set of commands to execute a user-defined test). Then a set of scripts would configure servers, databases and load balancers would rev up, and off you went. "Simple", said nobody, ever; that is, at least until containers came along!
Now though, your app is broken down into parts, and those parts move quickly, and by the way, your code still lives in your repo but also in a Docker repo, so they all need complex version control mechanisms, traceability/audit, and orchestration in order to be herded into production.
In delivery, many tools still deliver the same functionality as before, adapted for containers, but this isn't enough anymore if you want to get from point C (images built) to point Z (production running). What about binding artefacts to the application as services? What about reducing runtime for efficiency but also IP protection? What about automated stop/start and redeployment hooks? What about observability for this complex system?
In deployment, there is a rising class of CaaS tools (see our post here for how that term can be mis-used), but they mostly focus on getting Kubernetes clusters up and running quicker than through a command line. But infrastructure is only as good as its support of the app layer: what about dynamic scaling? What about non-container workloads like databases? What about firewall management? What about control over what gets deployed where?
Lastly, if you’re an SI or MSP, come talk to us in person about your views and experiences at AWS Re:invent in Las Vegas, NV, and Kubecon in Austin, TX.