Practical Cloud Native: What Works, What Doesn't • Sarah Wells • GOTO 2021

This presentation was recorded at GOTOpia February 2021. #GOTOcon #GOTOpia

Sarah Wells - Technical Director at the Financial Times

ABSTRACT
The way things fail changes when you move to cloud native. These systems are much more complicated to run and you can’t just hand them over to a separate operations team — but the ability to release changes quickly and deliver real business value makes the adoption of cloud native well worth your while.
Sarah will walk through the key elements of a cloud native approach, explaining what value each provides and what the impact is on your teams, your process and your culture if you want to be successful in building and operating your software.
Sarah’s experience building container-based microservices systems at the FT led her to taking over responsibility for operations & reliability, building tools to support operations and developer experience. She has a lot of hard won experience [...]

TIMECODES
00:00 Intro
01:00 Moving to the cloud
02:55 The cloud native approach
06:15 Why cloud native?
10:34 What changes?
10:59 1. Deployment
15:09 2. Architecture
21:04 3. How you build things
26:41 4. How you test things
30:21 5. How you support things
31:35 6. What your organization looks like
35:47 Outro

Download slides and read the full abstract here:

RECOMMENDED BOOKS

RECOMMENDED BOOKS

#CloudNative #Cloud #Microservices #ContinuousDelivery #CD #CICD #Containers #PaaS #DaaS #SaaS #DevOps #Observability #Testing #Test #Accelerate #TeamTopologies

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[itwchmurach]

I agree with statement that "Cloud Native systems are systems that benefit from cloud rather than run on it" however I can't agree that you need microservices to be cloud native. I designed and developed many monolith applications so called modular monoliths with clear boundaries between modules (subdomains) according to "12 factor app" principles and those apps use full capabilities of the cloud (continous deployment, running in containers, autoscaling, cost monitoring, backups, disaster recovery and so on).

[alevadnaya]

Thanks for this topic and clear explanation

[pm]

Hmm...
I agree that you need to make a way to "test in production" in the end - for those reasons.
But I don't buy that it's bad to be able to run the entire stack locally. There are situations where you need it (often in debugging). That doesn't mean you do it always, but you should be able to at least spin up ad-hoc disposable dev-systems for parts of and the whole stack. ... also on you local system.
... which is also one reason, I prefer containers as the building block over FaaS.

You have to adjust the sound quality, it is not a comfortable conference to listen to

[FlaviusAspra]

I kind of don't agree. I have created clusters from scratch myself multiple times. Measurably, I could set up a cluster in 2 months, with various services and functionality for which Amazon probably needs years and multiple teams.

It's way more fun, and you can fix things yourself much faster.

As for the amount of learning: a lot. Lean software development also optimizes for learning, it's a core tenet.

At the company where I'm at currently the CTO, we release 10 times per day, team of 4, onto our own cluster. The hardware is hosted somewhere else, and that company needs 2 hours to give us new machines. We don't have automatic scaling, but it would be easy to add.

The whole cluster costs us 5 times less than any cloud provider and we have much better performance.

We simulate the whole cluster with libvirtd, including a LB pair, 1 minute is spinning up the cluster. On Amazon, spinning up the same cluster needs 5 minutes.

I could go an and on, but the advantages of doing your own are tremendous long-term.