Speeding up innovation with Arun Gupta

Arun Gupta is a Principal Technologist at Amazon Web Services. He is responsible for the Cloud Native Computing Foundation (CNCF) strategy within AWS and participates at CNCF Board and technical meetings actively. He works with different teams at Amazon to help define their open source strategy. Arun spoke at Codemotion about technology as a means to speed up innovation. These are just a few of the things he had to say, watch the video below for full impact: 

The three stages of innovation

According to Arun, there are three stages of innovation in enterprise:

1. Speed: You want to build something really fast, really quickly, put a stake in the ground, fail fast and recover.
2. Scale: You want to build something, let’s try this. Something really large, something that scales very well so that you can reach the masses.
3. Strategy: A more deadline-driven stage “where these companies who are server huggers know, they want to hold on to the data centres. They’re migrating to data to cloud. And these are deadline-driven, because essentially, if you think about, you know, there is two three year lease for a data centre, and when that is expiring, that’s the time you start thinking about it, does it really matter to me? Do I want to keep my data centre or do just move to the cloud?

How do you measure the innovativeness of your company?

Arun asserts that for developers, innovation can be measured in time to value. This means “that I, as a developer built a feature, how long does it take for me to have that feature being realised by customers?  Does it take months? Now I pushed a feature six months later as part of a monolith is going to be available to my customers, or does it take days? No, maybe it spins out on a weekly cadence as a weekly bill that goes out. Or you have something called as a continuous delivery pipeline where every change you push automatically builds your software and releases it to the customers. The faster your release cycle is, the faster your customers can realise it.”

Smaller changes are better

In terms of software, we have realised over the years, that the smaller the better, the more the focus it is, the faster it builds, and the faster it drops.

Thre are however, key components that you require for in building those lots of small changes:

• Automated continuous delivery: You need to have automated Continuous Delivery pipelines. Because doing those changes by hand, it’s gonna take a while.
• Tagging, which allows you to tag the versions you need
• Flagging, A/B features where you can say turn this feature on turn this feature off.
• Canary testing, A/B testing, where you can say, “I’m going to release this new feature to one person of my traffic coming on Tuesday, 11 am. That is coming from a certain user agent, but maybe a mobile device or a browser. That’s where you start testing it. And then you expand from there based upon your health metrics on how that’s working out.”

Move from Monolith to microservices to innovate

“Take your monolith and split it across multiple microservices”

Because then the monolith that you have built over the years, which has probably a big build, takes a while to go and it takes a few hours, maybe as you’re running your tests, etc. If you translate that into a microservice-based architecture, then the build is fast because the focus is there, you’re possibly following the domain-driven design and all those concepts. And then your service can be built faster and can be put into production faster.”

Why Change one small thing at a time?

• Easier to tell if it breaks
• Easier to roll back to previous version
• Easier to measure time to value

In 2002, Amazon.com was one big monolithic application where it would take a while to change on one particular part of the application. “I just want to change the wheel of the car, but you can’t do that you just need to buy a new car altogether. And that’s sort of what led to the whole thought process that you know what? Let’s take that one big monolith and essentially break it apart into multiple microservices. So we went through that journey and back in 2009.”

Small changes also mean:

• Shorter MTTR (mean time to recover)
• Shorter MTBF (meantime, between failures
• Happy developers

DevOps: How to get there

Arun suggests there are some key components of DevOps and automation that are critical:

• Measure time to value: this includes the time to value for the whole team: Automate collection and reporting of commit to deploy.
• Do small things really quickly. “Start a project that is smaller in scope, you can start converting that into microservices. Get your experience, get a feel, what does it mean? You know, get some quick wins, and then you get a feel that Okay, now I can move forward with projects that are more critical to my customer workloads.”
• Measure the cost per deploy, “The bills need to be cheap. You want to start measuring your CPU hours, your memory hours that are being utilised, particularly if you’re running in the cloud because you’re getting billed for that. Essentially with each good push if need be, file an automatic ticket and that ticket automatically migrates through different stages as your build is progressing.

The value of distributed optimized capability

Distributed optimized capability means highly scalable but accessible “In case your app grows popular overnight, so that way, it can scale up automatically.”

Systems are cost optimised for high utilisation.

Cloud native principles and innovation

Cloud-native architecture is important when it comes to elasticity as your workloads increase any point of time and decrease any point of time. And so does your number of machines that are serving that request. Key principles include:

• Pay as you go, afterwards
• Self-service – no waiting
• Globally distributed by default
• Cross zone/region availability models
• High utilization – turn idle resources off
• Immutable code deployments

What is serverless and why is it important to innovation?

1. You are not managing the infrastructure.
2. Automatic scaling: with serverless, that scaling happens automatically
3. Pay for value
4. Highly available and secure

AWS offers a wide range of services in terms of serverless functionality:

AWS Lambda 

Serverless event driven code execution 

• Short-lived
• All language runtimes
• Data source integrations

“We have some of the most enterprise customers running Lambda at a huge scale. Take an example of FINRA. FINRA is doing half a trillion that is 500 billion validations per day using Lambda.”

AWS fargate

Severless compute engine for containers 

• Long running
• Bring existing code
• Fully managed orchestration

AWS  Fargate gives you the ability where you can leverage the containerization that you’ve already gone through, and then run it in a serverless way. Arun notes: “Today Fargate supports only ECS, which is our container orchestrator. But we are working on and are making that implementation for Kubernetes as well. So essentially, you can bring your deployments back, and ust run and scale the service.”