Evolutionary Change to Cloud Computing
In this post, App Dev Manager Mark Eisenberg lays out an approach to help organization kick start their cloud journey.
From data center to private cloud to public cloud:
- Everything is going to the cloud.
- Everything must go to the cloud.
- Everyone is moving to the cloud.
Why such drama? Why does everything and everyone need to go to the cloud and how does everyone feel about that? Maybe we don’t need to go to the cloud today. Certainly not everything has to go– maybe, just the parts that make sense and not necessarily the public cloud is where it starts. Private clouds are good too. By that, we mean real private clouds, not virtualized data centers. Virtualized DCs are good things too, but they don’t foster cloud native thinking. The key step on any evolutionary progression towards cloud computing is cloud native thinking. Without that, the destination is not a cloud, it is simply what we have always been doing– just in a different place. The likelihood of useful technology progression simply by changing geographic locale is quite low.
The first step is to set aside the “everything” idea. Start small. Build yourself a little cloud. Keep it homogeneous for now– the same servers, same switches, same load balancers. You get the idea. You’ll need a cloud management layer. Something like Terraform to manage the infrastructure or maybe Kubernetes to bring it to life. It just needs to be something that bolts on to your DevOps pipeline. Oh right– you need to build a DevOps pipeline. Make sure your Dev and Ops pioneers are working together on this. This includes your development practices, automated testing and integration, also continuous delivery. With all of the pieces in place, you are ready to begin your evolution into your own little private cloud.
By the way, you learn a lot by doing all of this but you could also skip all of that and use a public cloud. Microsoft Azure comes to mind. I’m told there are others.
Now you need a project– something that can leverage your little cloud’s elasticity. Start with a web application that has seasonal demand or maybe some sort of large calculation application that does not need to be kept running most of the time. You need something that can demonstrate how agile your cloud can be. Make it real, but keep the business criticality low. V1 is likely to be bumpy because your dev and architecture teams will be learning how to do things in a cloud native way. Mistakes will be made. There is no point in having natural selection take your cloud out early.
Next, architect and build your application. As the cloud visionary, your job is to keep your band of pioneers dogmatically cloud native. You will be able to back off the dogma after a while, but one of the best ways to get out of an old groove and in to a new one is to use a well-defined methodology. As you gain experience you can start peeling off the parts that don’t fit your needs.
This is the time to experiment. You chose a low risk project for a reason. Pause along the way. Are you following the chosen path? Most teams veer off because the new ways are not ingrained yet. Are people letting proper unit tests slide? Are they following the defined branching strategy? Are they checking in code regularly? Does the architecture allow pieces of the application to change without breaking or waiting on the rest of the system? Microservices excel at this, but there are other ways that work too. All require a shift in thinking.
Light
Dark
0 comments