Introduction to This Blog

In April this year, our CEO Jamie Dobson, CTO Pini Reznik and I were sitting around drinking Yorkshire tea and talking about how unclear the phrase “Cloud Native” was. What did it even mean? Did it just mean in the cloud? Was it a synonym for distributed systems? I suggested a blog series and in an arms race of content-driven ambition we settled on writing a whole short book on the subject of Cloud Native within 3 months.  5 months* later the book is finished and available from the Container Solutions website. Hurray!

We wanted to make it an easy read so every chapter is decoupled, covering one aspect of Cloud Native and can be read independently (meta eh?).

I’m a big fan of going to fancy coffee shops on expenses, so as part of my research I went out and interviewed genuine users of cloud-based, containerised and orchestrated microservice systems to find out how it had worked out for them. Big thanks to the folk at the FT, ASOS & Skyscanner for all their fantastic help and real life stories. I met all of the case studyees at conferences, which is a reminder to us all how useful it is to talk to folk you don’t know at conferences and meetups.

I’ve summarized some of our conclusions below but to get the full effect you can now read the ebook for free. It aims to be useful to everyone with a basic tech background. Enjoy!

* it took 2 months to decide on the cover.

What is Cloud Native?

Back in May, we asked the question What is Cloud Native? The Cloud Native Computing Foundation (CNCF) describes it as “distributed systems capable of scaling to tens of thousands of self healing multi-tenant nodes”. That’s a “how” (distributed systems) and a “why” (high scaleability and automated resilience), but it leaves some vital stuff out. Importantly:

• Most folk we meet are who are using Cloud Native tools are primarily looking for better development velocity rather than scale.
• A “Distributed system” is the end of the trip. There’s a ton of basic stuff that has to be done before you can get to the advanced level of full horizontal scaling, if you even really need it. We believe the earlier steps like cloud infrastructure and CI/CD are also part of the Cloud Native spectrum.

Why Go Cloud Native? What Are The Goals & Who Cares?

In our next extract from the book we went on to discuss three goals of Cloud Native projects that we commonly encounter in the real world

• feature velocity (speed)
• better support for scale
• reduced hosting and operating costs (margin).

We also talked about the kinds of companies that focus on each goal. For example, a company looking for a new or improved business model could target feature velocity. A company trying to expand an existing service to more users in more places might care more about scale or margin.

How Do You Become Cloud Native?

Like the logical folk we are, we then analysed the tools that people use to go Cloud Native.

• First we talked about why containers are so fashionable. Is there a good reason or is it a fad? (Spoiler, we concluded there were three very good reasons for containers: packaging, lightweight isolation and standardised interfaces).
• Then we pondered what dynamic management means (basically it’s using an orchestrator like Kubernetes). We discussed where orchestrators came from, what they have historically been used for and what they are being used for now.
• Finally, we discussed what microservices are, their pros and cons and some of the different use models for them.

At this point we stepped back and wrote a quick primer on common Cloud Native terms (or maybe buzzwords).

Where Do People Start?

By now we had a reasonable grasp of the what and why of Cloud Native. The next thing to consider was the delivery. So our following extract was on the means by which folk move from where they currently are to a Cloud Native setup. Their initial position might be a blank slate (though that’s a bit of a myth) or more probably a monolith. We concluded that gradually evolving a monolith to Cloud Native rather than starting from scratch is no shame. In fact, a leading Cloud provider showed us 90% of their customers are doing that very thing - evolving a monolith by splitting it into containerised, dynamically managed microservices - so it clearly isn’t crazy talk, it's actually the most popular strategy.

Problems, Dilemmas & Trade-offs

Now that we’d talked up Cloud Native we focused on some of its problems. Cloud Native is a broad paradigm so choosing to follow it doesn’t make all your architectural or cultural decisions for you. In fact, it gives you a whole load of new decisions to make and dilemmas to resolve, so we discussed those.

Some Real-Life Examples

Next, we doled out a dose of reality in the form of an interview with Pini Resnik, the CTO of Container Solutions, about common problems he’d encountered with early Cloud Native experimentation in the wild.

Security - The Afterthought (Hint - It Shouldn’t Be)

Finally, our bonus extracts were posts on microservice security according to Sam Newman, and container security according to Adrian Mouat. Both of which highlighted the security expertise you need to develop before you go fully distributed.

What’s Missing?

You may have noticed we’re a bit light on a few topics that are utterly critical to successful Cloud Nativiness. Continuous delivery and automation are vital to the goals of Cloud Native.

We talk more about continuousness (not continuity, that’s already taken) and automation in the book.

We’ve also talked very little thus far about the issues and dangers of distributed systems. Unfortunately, these are legion. You can read more about this in my recent article in The New Stack and I’ll be talking about it at the Velocity Conference in London in October.

Preposterous!

It’s all very well for me to write all these blog posts but there’s always the possibility that I’m “talking through my hat” (speaking utter rubbish about a subject I profess to be knowledgeable on, for those not living in the 19th century). To reassure us all on this front I interviewed a lot of interesting Cloud Native users who are behaving much as we’ve described. We’ve included those fascinating case studies in the book.

Finally I’m going to sum up our conclusions, but you’ll have to wait for another post for that because data suggests that at this point you’ll have finished your cookie and be drifting off. I could literally write any deranged thing here safe in the knowledge no-one will read it. But I haven’t so don’t get your hopes up. Or you could always read the book!

Image By LYDIA and her SALAD DAYS (Flickr: BANKSY : LONDON) [CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via Wikimedia Commons