This week I gave a keynote at New Relic’s FutureStack conference in SF.
Isaac Eldridge did a great write up here – 10 Thoughts on Modern Software from RedMonk’s James Governor. You really need to read his post.
Here is my own summary though:
Everything is accelerating in business, and the stakes are higher than ever. Economies are becoming more winner takes all. Which brings us to Highlander quote: “There can be only one”.
RedMonk calls practitioners the New Kingmakers. The companies that are succeeding are investing in building and rebuilding their engineering competence. The underlying factors driving the rise of the New Kingmakers are social coding and online learning, open source and the cloud. See my colleague’s excellent book for more about this revolution. One effect of the New Kingmakers’ trend is that access to developer talent is now considered more of a constraint than access capital – according to a recent poll of 1000 C-suite executives by Harris, sponsored by Stripe, called The Developer Coefficient. We are told we all need to become software companies, but it’s hard to be a software company. Data and services are what people want to pay for – this is The Software Paradox. The value today is not in the code, but rather in moats based on services and data.
Some companies are just moving so much faster than others. It’s almost comical. CI/CD is the on-ramp for everything good in modern software development. Better quality software, built faster. CI/CD drove the rise of Docker – the disposable infrastructure approach mapped really well to automated testing (unit, functional etc). But Kubernetes emerged as the orchestration environment of choice. Ops people bought into the model, and now it’s the defacto standard for all container-based workloads. All the major players have adopted it, including IBM, Mesosphere, Pivotal, Rancher, Red Hat, VMware. And of course Docker itself. See this post about Rancher: Treating Cattle like Cattle for more about convergence around Kubernetes.
We’re seeing the entire stack being rewritten and rebuilt on top of K8s, including everything from networking to storage. Unlike OpenStack, K8s didn’t begin with this relayering of the stack as a goal, but it’s happening. The next big thing, on top of K8s is likely to be service mesh, automating configuration, security, policy etc – allowing for sidecarring and routing.
The industry however hasn’t been doing a great deal of discussing Istio use cases. It seems to me that one is canarying (selective deployment before broader rollouts). Also see blue/green deployments (maintaining duplicate infrastructure, cutting over traffic from one to the other as new services bed in. Calling these approaches just “CI/CD” perhaps doesn’t go far enough “Progressive Delivery“ is what I call this basket of routing-based approaches for deployment toolchains, with feature flags, canarying etc. taking full advantage of container native cloud infrastructures.
Related – so what about how developers work – why not do everything through Github, with Git maintaining state in a declarative infrastructure, managing deployment by K8s? The Pull Request is the unit of work and collaboration. Weaveworks came up with the term “GitOps” to describe this pattern.
Even with ever more automated testing, we’re still going to have failures, requiring debugging in production. Today we develop software with an expectation of failure. So how we deal with issues? If we have a desired state, we also need deep insights into the actual state. This is control systems 101. The term being used in the industry at the moment is Observability, which goes beyond monitoring and traditional APM. It’s tracing, logging and monitoring across huge event data sets, with real time query. There is a a clear shift of perspective – a developer writes code for it to be understood. This responsibility is as anything in the testing tool chain. Follow @jbd, @copyconstruct and @mipsytipsy to learn more about O11y – they are all doing amazing work in the space.
So with Progressive Delivery, Observability and GiTops style work we also need more flexible automation than ever, with better, richer, managed APIs. Automation as code- everything needs to be programmable.
All of this stuff can be rather complex though – Kubernetes is not for everyone, so AWS Lambda is for the “laggards”. Which has driven serverless approaches. With Lambda there is no need to think about all the K8s stuff in building stateless apps. It’s 12 factor by default and design, totally opinionated. Lambda is driven by the laggards. Serverless goes further than AWS Lambdas however, with event triggers across different infrastructures, clouds and services, for example through the new Cloud Events spec.
Thinking about hosted managed services which abstract away infrastructure, and supre clean APIs brings us neatly to Stripe – which has rewritten the rules in terms of service consumability.
Which took me to some enterprise customer stories.
Auto Trader UK rethought its RFP processes in adopting Stripe, based on the ability to build quickly, enabling the New Kingmakers to be more effective.
Target has invested heavily in people, from 30/70 internal/consultants to 80/20 internal/external, hiring 1000 people in 3 years, with modern open source-savvy skills. Target is also now training third parties in its dojo. The best way to learn is to teach after all. Target is K8s native – every store will run Kubernetes.
Allstate created Kompozed labs, a facility teaching agile, improving how it builds software.
eBay is now going all in on K8s, being more explicit about the new basket of container native technologies and open source contributions
It’s not all good news on the enterprise side of course. I pointed to an absolutely brutal takedown of BA in the FT for not investing in software development. This was the first big breach of the GDPR era, and this story is merciless.
Organisations need to jump on the bike and learn the new approaches – go from balance bikes to bikes without the training wheel stage. Not everyone will make it – change agents, persuadables and heel diggers (you may need to lay off the heel diggers, not everyone will be ready to learn new skills for the new era)
Concluding –
- Create path finding teams
- Make open source contributions
- Container Native is where the puck is going
- GitOps
- Observability
- Make Operations and Responsibility pervasive
- Refactor for services
- Break down large teams into small teams, loosely joined
- Reshoring is a thing. Close to the Business. Close to the User
- Rebuild engineering culture and competence
- Rethink procurement
- Invest in people and training (but not everyone will make it)
Here are my slides
This was a paid engagement. New Relic also paid T&E for me.
No Comments