What is Cloud Computing?

Cloud Computing has gained quite a bit of momentum over the last decade. Yet, it remains a mystery to many. So, if you haven’t had a chance to learn about Cloud Computing, don’t worry. In this post I will tell you what is Cloud Computing, it’s key characteristics and what benefits it brings to you as a user. I also recommend to watch the following video for a quick introduction to Cloud Computing.

Cloud Computing Overview

Simply put, Cloud Computing can be defined as follows.
Note: I am using the term “resource” to refer to any cloud resource (such as, a virtual machine, a database instance, a load balancer, etc.)

• Create resources on-demand
  Most Cloud Computing vendors can create resources in a span of a few minutes! For many folks coming from a traditional IT infrastructure, this is a big leap where they may have seen provisioning times in the upwards of days to weeks.
• Self-service based management
  As a user you can manage your resources fully without going through a support or IT person. At the same time, there are enough controls available to make sure users cannot disrupt each others’ resources.
• Grow/shrink infrastructure on-demand (a.k.a. “elasticity” or “(auto) scaling”)
  This is where most Cloud Computing vendors shine. In a traditional IT infrastructure, we have to typically go through procurement process to get new hardware to host the capacity. Cloud, on the contrary, gives perception of infinite capacity. While that is not true in reality, the end user experience resembles this for the most part.
• Pay for what you use (a.k.a. “utility” model)
  That’s right! You don’t pay for hardware. Neither do you pay for the support cost (or what IT calls “AMC” (Annual Maintenance Contract)). You just pay for the resource usage.

Sounds simple, right? And, it is indeed. The most successful Cloud Computing vendors offer these capabilities in a very simplified manner making it easy to consume practically by any user.

There is a term often used in Software industry called on-premise/on-prem solution. This generally refers to a solution that is directly deployed in your (or your customer’s) data center as opposed to running in cloud.

Cloud Computing Models

Following are the most prevalent forms of Cloud Computing in use today.

Cloud Computing Model	Description
Infrastructure as a Service (IaaS)	Create and manage raw infrastructure on-demand (such as, virtual machines, load balancers and storage).
Platform as a Service (PaaS)	Create and manage an application platform on-demand (such as, database or an application server).
Software as a Service (SaaS)	Delivering and managing an application via cloud as opposed to installing it on-premise. Typically offers multi-tenancy, transparent upgrades; no maintenance required by customers.

Cloud Strategies

Most organizations use one of the following Cloud strategies.

Cloud Strategy	Description
Public Cloud	This strategy uses a specific public Cloud Computing vendor, such as, AWS to deliver the Cloud solution. Many small companies and startups find this model attractive as this reduces their infrastructure management overhead significantly.
Private Cloud	Organizations with existing data centers often like to convert it into Cloud Computing model (on-demand, pay-as-you-go, etc.) a.k.a. Internal Cloud. This is often done alongside an infrastructure consolidation exercise to make the infrastructure tailored to the most optimal end-user experience. Typically, mid to large Enterprises follow this model.
Hybrid Cloud	This is a combination of the “Public Cloud” and “Private Cloud” model in which certain components of the solution are hosted in the public Cloud and some in the private Cloud (often for security reasons). Example, the web tier may be hosted in the public Cloud, but database is hosted in the private Cloud. Again, this is a popular model in large Enterprises.
Multi Cloud	This is a combination of all! Organizations who have already realized the potential of Cloud (or believe in it strongly) often don’t like to have a vendor lock-in. So, they choose to go with at least 2 Public Cloud vendors and their own Private Cloud, if any.

Where do I begin?

The simplest way to begin Cloud Computing is by getting your hands around it. Most Cloud Computing vendors offer a try-and-buy type model. For example, Amazon Web Services (AWS) offers a FREE tier for 12 months that lets you try out most of the commonly used services. You can sign up for AWS at the link below.

https://aws.amazon.com/free

In rest of this post, we will talk about more practical points around Cloud adoption and readiness.

What is your motivation to move to Cloud?

I know, I know. Almost everyone is doing it. That’s ok. What are you trying to accomplish? It is interesting that at times organizations may spend several months working in Cloud and yet may not know what exactly are they trying to accomplish and is it really working? It’s not that they do not want to know. They just don’t know what and how to get there? Once you move past basic prototyping, this is where you have to start understanding where does Cloud fit in your overall strategy and what is the best way to leverage? I often like to say “Cloud is a journey and not a destination”.

Here are some reasons/motivations that I have experienced and may sound familiar to you as well.

• There is a mandate from senior leadership to go all Cloud in ‘X’ months.
• Peer pressure: Other companies in your space are getting on to cloud. And, so must ours.
• Our IT department is not able to cope up with our needs. We can manage it ourselves in Cloud. This is quite commonly seen in development and QA environments.
• Development of a Software as a Service (SaaS) solution.
• We got a good deal from Cloud vendor! Let’s use it.

You see the motivation could be speed and agility to multi-year strategy or a combination of some. But, it is important to understand that as it is an important driver in how you approach, architect and deploy your solutions in Cloud.

Everyone has a perspective towards Cloud

Before we delve into details, it is important to understand that while everyone has same motivation, their perspectives may not be the same. And, for the right reasons. For example

• An R&D (Research and Development) Executive’s perspective may be to get to faster releases with good quality.
• A Product Manager’s perspective may be to offer different product options and ease of demo.
• An Architect may be looking at micro services, Cloud vendor offered services, different deployment strategies, better high availability and resiliency.
• A Developer may be looking at being able to play around with different Cloud services APIs and to gain more technical skills.
• A QA team member may be looking at getting machines and standing up the infrastructure quickly.

The reason I am highlighting is once you start your Cloud journey, you will run into these aspects. Obviously, every one is right from where they are looking at things. So, my recommendation to folks who are driving the overall Cloud project (be it Architects, managers or other leaders) is to be respectful of everyone’s perspective. In the end, it is a team’s deliverable!

Getting ready for Cloud

Common Terminology

Following are some commonly used terms in Cloud world.

Term	Description
(Auto) Scaling	A Cloud capability to grow or shrink infrastructure on-demand. This often refers to adding additional capacity to existing cluster, such as, increasing or decreasing the number of virtual machines depending on the load. The “auto” scaling part refers to making this automatic based on event(s) such as, based on resource utilization.
Multi-tenancy	A fundamental capability often found in SaaS solution to be able to use the same deployment for multiple customers. Each customer’s data is completely separated from others to enforce security.

Considerations for Architects, Designers, Developers and Quality Assurance

Typically, Architects and senior technical members work on designing the Cloud-based solution and initial deployment. Here are some key considerations if you are a technical Cloud Leader.

• Identify how your application tiers would be hosted in Cloud. This may not be same as mapping a tier to a machine in Cloud. You may have certain components that may need to be taken out as they be more intensive than others, but do not run all the time (or do not need to consume resources of the main application tier). Start preparing a simple deployment diagram and you may find it interesting that it does not look the same as your on-prem deployment diagram.
  • Also remember that Cloud offers scaling capabilities. This is an important aspect that can help you come up with a more appropriate Cloud deployment based on which tiers you would like to scale independently.
• Are you moving an existing on-prem application to Cloud as a SaaS offering?
  • You may have to think about multi-tenancy more thoroughly.
    For your on-prem application, customers installed it directly and their data was with their installation. Although you could technically host multiple instances of your application in Cloud (an instance per customer), you may want to evaluate if it would be better to host a single application instance that can serve multiple customers. Hosting a single instance (which is commonly used approach for SaaS) has many advantages. But, it is important to evaluate this in the aspect of your needs and what kind of changes it brings in to your application.
  • Would you be migrating existing on-prem customers to Cloud? What will be their migration path?
  • What happens to the existing build-to-release processes/tools/automation? Can these be leveraged? What changes are needed?
  • Does the application require specific hardware resource(s)? Are these available in Cloud? If not, can these be decoupled from the application and communicated in a hybrid cloud manner?
• Resource Sizing: Finding out an optimal size for your resources (such as, virtual machines, databases) could take a few iterations. Make sure you keep room for doing this exercise. A good starting point is to start on the conservative side. It’s generally easier to go higher in size.
• High Availability: Evaluate the high availability capabilities offered by the Cloud Computing vendor and see this can be best applied to your solution.
• Scale in/out: What will be the scaling criteria? At times, you may be able to resize the resource and in certain cases you may want to stand up a new resource altogether. Likewise, decrease the resource size or remove the resource when not needed.
• Cloud Security is perhaps one of the most complex topics. Companies are often required to follow regulatory and compliance processes to ensure their offerings are as secured as possible. When you host a solution in a Public Cloud in any form that just brings in more questions – both from customers and security auditors. Again, for the right reasons because the risks are often too high. You may also be required to gain one or more accredited certifications to substantiate your claims. As a technical Cloud Leader, you want to make sure that security is not an after thought. Granted that you may not know every single thing and not everything can be done in the first deployment, but you should review any critical security related aspects with your technical leadership, security experts and other stakeholders (as appropriate). Often, it’s not about having every single thing done right away, but having priorities identified and ensuring there is plan to address. Having said that my recommendation will be to be conservative, esp. when it comes to security. Here are some simple measures that you can take right from the beginning.
  • Do not expose public ports unless absolutely necessary. A good starting point is to not have any public port in the entire deployment other than the one for web traffic.
  • Expose only relevant ports and only to relevant components/consumers. For example, if you have web, app and database tiers and only app tier talks to database, no need to expose database port to the web tier subnet. Similarly, avoid use of the 0.0.0.0/0 as source. Be specific.
  • Use private subnets as much as possible and avoid/minimize hosting components directly on public subnets. This reduces further chance of accidentally exposing instances.
  • Avoid direct shell or console access to your resources. Many organizations use jumber boxes or bastions to gate access to the resources.
  • It all starts from your development Cloud. Do not undermine the importance of security of your development Cloud. It’s not just important for production. Many times you may be able to identify weak spots or other potential issues ahead of time. An issue identified in production is always more expensive to resolve.
• Cost Focus: What good is a Cloud deployment that breaks your budget? The focus on cost has to be from get go. Once you have done the set up, you will invariably find it challenging for teams to make changes. However, if you start conservatively and only add capacity if absolutely needed that puts you in a better spot. Likewise, stop resources when not in use. And, if these will not be in use for some time, perhaps get rid of these. You can always create these when needed.
• Not all environments are equal! Yes, you do not have to run the development environment to be of same resource type as production. So, choose wisely. Again, starting on the lower side is usually a good idea.

Build to Release Process

DevOps is the buzzword these days. And, we will talk about it in more details in another post. But, for now, the same agility that Cloud platform provides, you need to bake the same as part of your build to release process. Be it unit testing, QA, automation, security testing, performance testing and any other critical gates, you want to make sure you align these for an efficient delivery. Of course, it will take time. But, just like other aspects, prioritize and figure out the plan. Have deliverables that provide value and that can be easily maintained as you continue. The selection of right tools and processes is equally important here.

Considerations for Executives and Senior Leadership

You are the sponsor. So, your stakes are high and obviously you want to get the best out of your investment in Cloud. Here are a few tips I recommend.

• Identify your priorities. Be realistic! For example, is going live in Cloud your first priority? Or is being able to push every code change to Cloud the most important thing?
  While it is true that you want the teams to deliver their best on all fronts, the reality is transitions like these bring several technical and process challenges. Setting multiple priorities takes a toll on the team and causes unnecessary distractions. It is highly recommended to discuss your priorities with the Technical Leadership team. The idea is not to set the bar low. But, to be more realistic. It’s perhaps better to have one deliverable with good quality than having 2 deliverables that are not completely done.
• Identify the release to customer value realization cycle. How are the customers going to sign up? What will be the sales model? Would you offer try and buy? How will the customer realize value? Which all industry certifications would be needed? What other process points need to be addressed to make sure once the solution is available in Cloud it will sale? Indeed these are not easy things. But, these are critical to the success of your solution. I highly recommend making sign up process easy and preferably with a simple try-and-buy approach that lets customers evaluate the fitness of solution for their needs.
• Be an inspiration: Sometimes Executives underestimate the amount of influence they have on the teams on a day-to-day basis even though they do not work with the individuals daily. Support your team, fuel them with energy and inspiration, show them how their hard work is going to help the company. A pat on the back goes a long way!

We are in Cloud! What next?

Great! That means your journey has begun. Now you have to identify what will make it even more impactful. Few points to ponder.

• Do you have room to optimize cost?
• What other process or tools efficiencies can be brought in to be even more effective?
• Are there further security hardening areas that can be improved?
• What about any architectural improvements that can be done to gain better value (for example, further componentization to improve re-usability)?
• Are you monitoring critical metrics for effective operations? Can you catch an error before your customer sees it and rectify the situation?
• Could there be improvements done to the overall business model to improve customer experience/adoption?

 

If you made till here, congratulations! Hopefully this has given you enough firepower to make your Cloud journey less cloudy. Feel free to share your experiences in the comments.

Happy journey!
– Nitin