How Cloud Services Have Changed Application Development

I am often asked, What is the cloud? In response, I point to Dropbox, a service that allows users to store files both on their computer and ‘The cloud ’. As you have very likely experienced for yourself, working in the cloud enables you to save and close a document and then open that file on a different computer you could pick up working on it where you left off. Beyond this most basic use case, I've also been exploring how the cloud has come to offer much more, especially in the evolving world of application development.  

While looking for a cloud service provider for a project I’m developing at home I looked at the offering from many providers and selected one (IBM Cloud) to investigate much deeper. This home project is building a platform for managing the systems in my house. In a commercial building this is very commonly called a BMS (Building Management System), for my home I call it a HMS (Home Management System). You can read more about this project here.

An Overview of Cloud Service Types

A more thorough explanation of a cloud service might be it’s a pool of computer software and hardware resources available outside of the customer’s premises. Adding to that there are public cloud offerings (your software hardware is comingled and shared with other customers) private cloud (your software and hardware is dedicated and specifically dedicated to you within the service provider’s data center) and hybrid cloud where it’s a combination of both. The services a cloud provider may be divided into 3 categories, IaaS (Infrastructure as a service), PaaS (Platform as a Service) and SaaS (Software as a Service). With IaaS you provision hardware, PaaS include hosts with OS, hypervisor and virtual machines (vm’s), with Saas you provision software (applications - for example salesforce.com or Microsoft's Office 365).

To help put it in context I’ll use a great automobile analogy I learned from IBM’s documentation. With IaaS its like leasing an automobile, you care very much about the specifications of the automobile, type of engine, body style, color, etc. With PaaS its similar to renting a car, but in general you’re less concerned about the specifications. With SaaS, its like taking a taxi, you’re even less concerned about the car, you merely want to get from point A to point B, quickly and safely.

The modernization of the Application

Many, if not most, legacy applications can be categorized as monolithic, this means all functions of the application are written in one long program. As an example, imagine the application an airline might use, one function of the application might be for reservations, another for payments, and another might be flight schedules There are many challenges with developing, maintaining, and updating monolithic applications. First, all programmers regardless of which area of the application they are working on must write code in the same language. Second, an update to any one area of the application will require the entire application to be redeployed and that may be a very tricky process so critical it is usually perform over a weekend and referred to as hero deployment. Third, if one area of the program is struggling to keep up with user demand anything the development team does will take too long to address the problem. In our example above, if the reservation function of the application is struggling to meet user demand there is very little the application development team can do. With the issue of updating, even if the developers were to make changes to the application, by the time that the application developer team could do anything the demand problem may already have subsided.

So in the evolving world of application development what is really new? Three big advancements: microservices, containers, and continuous delivery mechanisms.

Microservices: Going back to my example of an airline’s application, however, instead on one giant program, imagine each function of the application as separate program. Each program function (reservations, payments, flight schedule, etc.) would be a separate microservice or in other words a separate program. Each microservice would share data with the other microservice through an API (application programmable interface). Since each microservice is a separate program, each can be written with a different programming language so the application team can choose whichever language is the best choice for their team and their microservice.

Containers: Early examples of containers date back to 2008, although they have recently become very popular with container orchestration services like Kubernetes and Docker, but more on that in a bit, first: what are containers. Think of containers as virtual environments that only includes the essentials for running your application: an operating system, application code, and application dependencies. Orchestration services like Kubernetes, Docker, Rocket create and deploy the containers in the form of worker nodes. Returning to our airlilne application example, if the reservation microservice is unable to keep up with user demand additional containers with the reservation application can be deployed to meet that demand.

Continuous Delivery: This is the third component to the modernization of application development. Continuous delivery is exactly what it sounds like and easiest to explain with a simple example. I have an application running in an IBM container (Cloud Foundry) that performs analytics and heartbeat functions on another data collection application I'm running locally. I use GIT for controlling and cataloging the different versions/revisions to my code, GIT HUB as a repository for my code, and Cloud Foundry as my container orchestration service. Once I make changes to my code I publish (or commit) it with GIT, because I've configure an IBM integration and continuous delivery services with my cloud account my cloud application recognizes there's a new version (because of the integration with GIT) my IBM Cloud container services (Cloud Foundry) rebuilds the container, pulling in the new code from GIT HUB and redeploys the worker node. So even more simply state typing one command in the terminal window of my home computer pushes my code to the cloud and redeploys my new application in a new container. Strangely and a bit more complex, but this is very similar to the initial example I gave for what is the cloud – the file  that syncs, AKA Dropbox.

So how does this connect to the project I'm working on at home? My first application, 6 years old now, was one long program where I attempted to do everything; read sensors, write to a SQL data base, update a GUI, and send notifications. It was long (about 2,000 lines) and bloated with repetitious code that was error prone and very difficult to update. The next version I wrote has one program that just reads sensor data; whether wired or wireless or if connected to another computer, another application that displays the data in a graphical user interface, and another program for performing analytics. This last analytical program runs in a container in the cloud, stores its code in a GIT repository, and finally updates and redeploys the container when changes to the code are detected.

In my next article plan to compare the different clouds service providers I've tested and share my experiences, including the simple scoring system I put together. Currently I'm experimenting with different visualization libraries like D3, Seaborn, and AltAir, These are very very neat and when coupled with a tool like Jupyter-Labs are really fun to play with and are also a topic for a future article.