Application Building: Traditional Versus Cloud-Based
The cloud continues to grow and dominate the business sector. According to a 2017 article in Forbes, Gartner predicts that the public cloud computing market is expected to reach $411B by 2020. This is double the revenue size of the market as it was in 2016.
This seems like an astonishing growth, but when you sit back and think about it for a moment, it’s not too much of a surprise. There are still multiple industries that have made very minimal moves to the cloud, such as finance or healthcare. If cloud computing were an ocean, most of these industries would still be on the beach, occasionally dipping their toes into the water, while the rest of us are happily swimming around, shouting “Come on in guys, it’s lovely in here!”
However, I am starting to see a momentum shift. Just the other day, an ex-colleague of mine from my investment banking days asked for the lowdown on AWS, as they are thinking of moving one of their key investment applications into the cloud. Rather than pointing him to some very detailed (and to be honest, very dry) white papers, I decided to give him an illustration by comparing the traditional way of application creation that we both knew well, to the new cloud methodologies that I am now fully accustomed to.
The following describes the three-step process of building a new application and turning it over to development teams, framed by a comparison between the old and the new methods:
Step One – Estimating Application Requirements
Traditional way – Through a series of discussions with the application owners, developers, sysadmins, database administrators and storage teams, the team must estimate the required specifications of the hardware, storage, network bandwidth, etc. for the application. This involves looking at performance monitoring, capacity planning, usage statistics, etc. Finally, everyone agrees on specification and starts the purchasing process. This may involve using existing hardware, virtualization or brand-new hardware.
Cloud way – No discussions required. The team can scale the needed hardware requirements up and down in seconds, and add an almost infinite amount of storage space as and when it is needed. If the team gets it wrong, they can just trash the entire environment and start over again.
Step Two – Purchasing Process
Traditional way – This is a long, drawn out process dealing with quotes from vendors or third-parties, salespeople, internal office procedures, purchase orders, etc. It can take weeks or months to get things completed.
Cloud way – There are no middlemen, no salespeople, and no purchase orders. The purchaser just clicks a few buttons and they have the new hardware, as much or as little as is required.
Step Three – Installation
Traditional way – The data center staff have to rack and stack the hardware, network admins have to configure it and make it available, sysadmins have to configure it, storage admins have to make disk available for it, database administrators have to install the software, etc. All in all, the process involves several teams, multiple staff and a period of time that can range from weeks to months. On top of all this, the whole process must be repeated for each environment required.
Cloud way – One person can do everything mentioned above in hours. The new environment can be scripted and clones of the new environment can be launched and available in minutes.
Although this description simplifies process quite a lot, it does provide an idea of just what can be achieved with the cloud approach. It doesn’t even begin to cover the vast array of services that are available at the click of a button, provide high availability, full management and vastly simplify implementation.
Becoming a solutions architect puts you at the center of all this technology and makes you an integral resource for all companies. I spent 15 years working with databases and dealing with all the teams that surround that technology, but now I can do everything that those teams do and do it much faster, thanks to the cloud!
This content first appeared on my Simplilearn blog channel: