The Highlights from Cloud-Native London 2019
I attended the CloudNative conference last month, and although it was weighted towards open source and Docker, Kubernetes and containerisation (say all 3 fast and you sound clever), the core principles were more relevant than ever. It was a 3-day event, but I am going to condense my thoughts into a short-ish article (the best bits, hopefully…).
Cloud Native — are you?
We all know IT is moving fast, but refreshingly this conference really was pushing the latest and greatest, particularly micro-services, functions, and continuous delivery — the proper meaning of it. The talks focused on how we can utilise cloud-only services and containerisation, with low or no-code solutions to build modern IT ecosystems and, importantly, maintain low management overheads.
This was the first time at a conference I heard FaaS being spoken about more than PaaS. The main takeaway point was re-designing our IT systems to be a collection of very small services (Functions, Logic Apps, Queues, IoT, APIs etc) that are interconnected via a common protocol, yet entirely independent. We may not even have much of a need for a traditional Web API on an App Service in the future.
Being cloud-native isn’t just about developers writing small apps or architects designing small services and containers. It’s a combined effort of DevOps, security, development, and architecture: writing and deploying code in a continuous and automated manner (every day) with no downtime and very low error rates; as well as designing for very high scalability and security — and letting the cloud provider worry about the VMs, the OS, maintenance and the actual scaling. We should embrace the shifting of responsibilities and exploit the potential cloud has.
What the Function as a Service is that?
FaaS is the next big thing — or it was for this conference! FaaS being essentially Azure Functions, Logic Apps, etc (or the Amazon or G-Cloud equivalents), with PaaS being spoken about as ‘old school’. Honestly, I’d never really thought about it in this way. But the main points were about building a modern IT service largely as Functions.
We should learn to move away from traditional Web APIs, even if they’re “small”. Create 20 Functions or Logic Apps as opposed to 6 Web APIs. If you lock down your security properly, I can see how scalable and performant this can be and the subsequent business value it provides. It also supports what I call the ‘holy grail’ — continuous delivery. DevOps aficionados will learn to love it if they don’t already.
Another take-away note from the FaaS PaaS SaaS IaaS acronym confusion I agreed with: can we please stop calling them “microservices”? It’s just “modern IT design”.
Continuous delivery — can we get it done, please?
Why do we worry about releasing at 5pm on a Friday? Because we’re doing it wrong. Why do we have planned release dates with lots of approvals and sign-offs? Because we’re doing it wrong. Why do we get regular problems in deployment, particularly around configuration? You guessed it…
According to the State of DevOps Report 2019 by Accelerate, the “Elite Performers” (that is, the top companies for continuous delivery) can deploy on-demand multiple times a day with:
1. A failure rate of 0–15%
2. Less than 1-hour lead time for changes
3. Less than 1 hour to restore an entire service
Comparatively, a company that deploys once a week to once a month has:
4. A failure rate of 40–60%
5. Between one week and one-month lead time for changes
6. One day to one week to restore a service
An important thing to note is that you cannot do continuous delivery without full automation, in all areas: code deployment, infrastructure provisioning (ARM/CLI/PowerShell templates) and automated testing (unit tests, UI tests, acceptance tests, Selenium, etc). If you do it correctly, you can do it with one button in Production. Every single time, reliably. Master templates, Nested templates, PowerShell scripts, and CLI — whatever your automation poison, get it done.
Some good reading — The State of DevOps 2018 report (the 2019 report is also out).
It starts from the beginning: right team and right technology
Refreshingly it wasn’t all about the technology: a core component of delivery success is the foundations of the team. To be an elite performer in the industry, you need an elite team. Not specific individuals, but a unit moving towards a common goal. What stood out with me from the conference was not only technology being the primary driver — it is also the people. A few key things I took away:
· No blame culture — who cares if it goes wrong! It will, it’s inevitable. What matters is working together to solve it. Failure is a chance to be better. Use it.
· Dissect why something failed and learn from it. Again, it doesn’t matter if person X pushed an incorrect configuration change. What matters is how we improve processes to prevent it in the future.
· Run game days — simulate a disaster scenario in pre-production. Then, give all the teams that would likely be involved 3 hours to figure out and fix it. You’ll be surprised at the results (you’ll find you’ve got more problems than you’ve ever realised!).
· Make the right technology choices — keep it as simple as it needs to be. Design your code and your architecture and release processes to match the requirements and don’t overcomplicate it. Someone has to maintain that wizardry eventually!
Most importantly, we’re all human. You should have a mixed team with varying skills and cultures. Bringing them together around a common goal is key. It doesn’t matter if you have a team of the A* best people if they can’t work together effectively or are always fighting to be “the best” — you don’t have a high performing team that cares about each other.
Who do you want to be — the Amazons or the Blockbusters?
Get with the Programme. The world’s best companies have the most complex and diverse IT estates. Netflix is purely cloud-hosted on AWS. Working for an IT company in the Microsoft practice, I think we should be delivering to our clients what the elite performers are doing in theirs: that’s why we’re hired, right? To be the subject matter experts and partners of choice for blue-chip companies, delivering large projects on time using the latest technologies.
Gone are the days (or they should be) of lengthy change requests and 50 approvals for a “big” production release. It’s just not the world we’re living in. If you stay in this space and don’t learn to be agile and automated to the core, you’ll likely end up as a Blockbuster.
Join the Capgemini Microsoft team and apply to available jobs here.
