It is a golden age for our business thanks to the internet, agile and the cloud.
Agile gives us great tools to navigate the cloud landscape. The thing that attracts a lot of people to Scrum is its belief that intelligence and expertise lies within the team members themselves, not the system. If and when they’re well-organized, they can focus their skills to solve a problem.
Scrum aims to put everybody that’s required into the same team and then acquire the right knowledge so that they can learn how to work together really well. As they mature, they acquire this ability to solve problems. This means they have to have agency permission to do things.
One of the realities is that in larger organizations, when you’re putting software out to production, there are a lot of things to consider like security and how it integrates properly. It’s not easy. There are pauses and delays, say while it goes to dev ops and sys ops, for example.
The cloud enables teams to take some of those tasks back into the team.
What is the cloud?
The common definition of the cloud would be that it’s self-service. You don’t have to ask someone else to create something from it. It builds in increments and it’s auto-scaling.
Amazon Web Services (AWS), for example, tries to push this idea of undifferentiated heavy lifting.
An example is two insurance companies that each have an on-premises data centre. That doesn’t make either of them better than the other. If only one of them had a data centre, that would be different. But since they all have data centres now, they’re evenly matched.
That’s undifferentiated, and managing your own data centre is, by that slogan, heavy lifting.
What you want to do is differentiate yourself in your business, and you capture those rules and opportunities in software. Let someone else to do the heavy lifting part, and do it better than you.
Freedom in the cloud
By freeing an organization from those kinds of responsibilities—like operating a data centre—its people are able to focus their efforts on more productive things—things that actually might set them apart in the marketplace.
This isn’t new. We’ve seen this throughout industrial history. Canadian Pacific Railway used to make their own locomotives. In Montreal, they used to have the locomotive works. Iron went in one end and locomotives came out the other. They made their own locomotives because they had to. There was no one around to do that.
That’s all changed. They buy their locomotives now.
Get someone else to do it.
Get them to do it more efficiently, safer and then we can focus on what we do best.
For a team—and, by extension, an organization—it gives more control end-to-end. It gives them speed and agility that an organization needs or a team needs to respond quickly. Put something into production quickly and also, just as importantly, experiment.
We worked with a company recently where they got a large cache of data every month from hundreds of organizations. They needed to then process it and give the results back to those same organizations. Their software licensing was based on a certain CPU power so of course, they bought servers to match that.
When they processed the data, it would take a day or two—sometimes longer. Then they’d learn something and have to reprocess it two or three times if they found some anomalies. And so they would max out the CPU license for only a fraction of the month.
The difference is that, with the cloud pricing, you’re just paying by the hour. So now, you can have a cluster of servers and, instead of running it in hours, you can run it in minutes. You’d run it for a few days and then stop. The cost might actually be the same, but now, you’ve gained a week. And if you need to react, now you can and you don’t have to wait days for it to reprocess again.
Amazon has over 100 services now.
And they offer so many opportunities.
If you wanted to do a mobile API that is auto-scaling, with messaging or notifications, you can create your own infrastructure of course. But why would you? It’s almost impossible to justify since the cloud is so much quicker and faster.
Why would you start speeding up your own on-premises infrastructure when it’s already available at your cloud provider? And one of the pricing models that makes it attractive is, on some services, there’s a free threshold every month. So the barrier to experimentation is very low.
Empowering the team
Now we’ve got the infrastructure to support us so we can give those decisions to the teams, we can give them the authority to put things directly into production rather than “throwing it over the wall” to another team. And it’s all of those little things that add up to make an organization more agile, robust and competitive.
An organization that has its own data centre will have a hardware refresh cycle. What happens typically is they will look at the decision whether they want to host it themselves and compare it to the cost of migrating things up to the cloud. That’s usually what gets their foot in the door; they discover that it’s about the same price or even less.
Once they’re in the door and the dust settles on the migration, they look around and say, “wait a minute, I didn’t know we had all these things available to us. There are things that we’d like to do that we didn’t consider before because we had to create our own infrastructure. Well it’s already here now. Maybe we can start doing those projects we were just dreaming about before.”
Taking to the skies
There are well-worn paths to migration. The first thing is to lift and shift: you just take whatever you’re doing on-premises and you do exactly the same thing in the cloud. No changes whatsoever.
The next thing is you start refactoring parts of it. A part of a monolithic application gets split off; part of it is on-premise and part of it is in the cloud.
The third stage is typically when you rewrite something to take advantage of this cloud-first architecture. Monolithic software probably has dozens of tasks that it performs. If one part needs to grow or scale at a certain time of the day, month or season, it does, and you don’t have to plan for it. If you only want to change one part, you don’t have to redeploy the entire monolith.
The the cost is so small it’s astonishing. You wonder sometimes how they make money. But they do.
But is it safe?
One of the concerns I hear about moving out to the cloud is security; the idea that, because they can touch their own data centre, it’s safer.
But when you expose it to the internet, I would argue that it’s less safe and in fact, the cloud providers are safer. They have way more resources and people available to them. They are getting reports from the entire world and sharing that. That is their business. So I would argue that security is better up in the cloud.
Amazon has its own code pipeline that offers continuous integration, continuous deployments. It makes it easier to push things out in a production. So if the team itself watches the performance, the cloud reports back nicely what’s happening so a team can make better decisions.
- It could decide to scale differently.
- It could use a different instance size.
- It could write its code differently to take advantage of that new knowledge.
There’s also cost savings involved in that. Amazon has four different pricing models. If we go with the more traditional way of architecting something, the pricing model is paying by the hour. Everyone’s familiar with that.
Beyond that, you can commit for say, one, two or three years. You get a huge discount if you know that you are going to use it consistently.
There is also the server-less model, which we’ll save for another article.
Cheaper and better
Another thing Amazon does is auction off their unused servers at around a 90% discount. The bargain is that they could take it away from you at any time if they can sell it at the full price. They give you a two-minute warning that they’re going to shut it down and take it away.
You could create a whole fleet of these discounted instances. And if they come and go, you would architect your solution and have something that can orchestrate all that.
There are tools to do all that with CloudWatch. You’re getting constant information. If you wanted to you, you could reduce latency on the web with their content distribution network CloudFront. Say you were going across say the continents. They have many regions around the world and—if necessary—can cache it in another region like Europe or Singapore or Australia. The latency for those users would be much lower.
This all gives the team and an organization closer interaction from end to end. It gives them the information they need to design the optimal solution, and the feedback loop is very short. Less learning is required and the cost is significantly lower.
If you find this useful, please consider contributing with our
“Value for Value” model.