SQLServerCentral Editorial

Cloud Pace


Recently, a user responded on SQLServerCentral to something I'd written on Azure, asking how do I keep up with all the changes. I wrote back: "Between the complexity and pace of change, I’m always learning something."

To be clear, I don't really keep up. Even just trying to read all the Azure Announcements can be overwhelming, especially if you want to set up a quick demo on any of them. Even trying to get through the (free) e-book, The Developer's Guide to Azure, was a chore. There were so many things I hadn't heard of or barely knew about that I had to stop myself from logging in and trying something to get to the end.

The Cloud isn't really anything new. Not very new. All the IaaS stuff has been around for a long time, where you could rent a machine from some data center owner. The PaaS stuff is a little new in its implementation, but the idea is what many developers have dealt with in organizations where they didn't have any administrative privileges. The database was just a database, no server involved.

The biggest change I see with the "cloud" is the pace of change. Companies lose some of the overhead of dealing with different departments and getting resources provisioned. Because cloud vendors are working at scale, they've built tools that allow customers to spin up new VMs, databases, even clustered systems in minutes. Much of the tedious complexity has been removed, which allows users to just move forward with building systems.

The move towards DevOps, with a focus on automation, means that vendors also build new platforms, capabilities, and options that we can use at a furious pace. The choices we have can be overwhelming at times, with no one person really able to keep up with the myriad of possibilities.

To me, this means two things for your company. First, you always need to have some experiments running. No proof of concepts that will be turned into applications, but true developer or operational experiments where people try out an elastic pool or machine learning or a K8s replica set of Hello, World containers. Your staff needs to be learning and sharing with each other in small ways.

The second thing is that you need to limit the technologies in use. While there are many amazing and useful new services, you can't bounce between them and support an unlimited number of choices. Limit the number of technologies (languages, frameworks, platforms, services, whatever) to the few that get the job done, with a process to add new ones if a rational case can be made.

The bottom line is that it is important to keep learning, evolving and using better technology over time, but we have to be sure that most of our time is spent working on the software we're building, using the knowledge we already have. We're paid to get work done and while learning is a part of that, it's a small part. Mostly we need to be doing the other parts of our jobs.