Cloud architects are in demand. Six-figure salaries and solid job prospects are driving large numbers of IT professionals to get certified with AWS, Azure, or one of the other large cloud providers, but the responsibilities of the position are often unclear. As a cloud architect, you are the planner and designer of cloud-based infrastructures, and with the growing desire for data centers to be moved to the cloud, your competence is critical.
The cloud allows technicians to quickly launch servers, databases, and the equivalent of entire datacenters within minutes. This speed is amazing for responsiveness and adaptability, but without proper planning, the design may turn out to be inefficient, expensive, and open to malicious hacks. This is why the role of cloud architect is so important. It is your responsibility to make sure that the environment is designed to meet or exceed the requirements and expectations of performance, cost-effectiveness, and security.
I am a huge proponent of moving to the cloud, but there are pitfalls that aspiring cloud architects need to avoid. Human error will never cease to exist, but many of the worst mistakes in this field are more involved with how you approach designing a cloud architecture than the day-to-day administration of one. Successful organizations and professionals learn through experience and training, and we can jumpstart that process by examining some of the worst offenses.
Here are four mistakes you can’t afford to make as a cloud architect
1. Leaving Hardware Static
Hardware choices that are set in stone in your local data center can be changed at a moment’s notice in the cloud. If you purchase a server to host your web site and months later realize that the processors aren’t powerful enough, there is not much that you can do about it beyond buying replacement hardware and absorbing the cost. Cloud architectures don’t allow you to make changes based on demand, you are expected to make that change every single time you think it is necessary. The idea that you should treat your hardware as an elastic resource is a pure cloud concept.
One of the easiest ways to describe the cloud is that you are using someone else’s computer. The hardware for your infrastructure is housed in a datacenter owned by one of the cloud superpowers, but everything else is the same, right? Definitely not. If you treat the cloud as another remote data center that you need to manage as a static asset, you are missing the point entirely, and your company will suffer for it. Scaling that is automated and based on demand is a prime example of something that is impossible to implement in your own datacenter but has become commonplace best practice in the cloud.
This concept of elasticity will not just help you in terms of performance, it also helps managing costs. If you do not adhere to it in the cloud, your costs will skyrocket as well. One of the major differences of cloud vs. on-prem is that you pay for what you use. Failing to right-size your hardware or to terminate currently unnecessary resources can dramatically increase your monthly bill.
2. Not offloading the burden
One of the prime benefits of designing in the cloud is that you are offloading hardware responsibility to someone else. You do not have to plan ahead for capacity because you know that virtually unlimited resources are yours when you need them. There is no reason to stop with hardware. Serverless (aka managed) technologies abound, but most people misunderstand how they work. Serverless does not actually mean that there are no servers. It means that their management is no longer your responsibility. You can focus on your data, the user experience and designing your next architecture. Leave the joyless jobs such as patching servers and applications to someone else.
The mantra you should repeat is “Services not Servers.”
Cloud providers offer numerous services that entirely replace the need for direct management of servers. If a situation calls for a database, do not make the mistake of launching a virtual machine, installing an OS, and setting up the database. Choose a managed service that does all of that for you. Instead of offloading the responsibility of the hardware, have your provider manage the OS and DB software as well.
3. Making Assumptions About Security
The most obvious mistake you can make as an architect is to leave your organization’s systems open to attack. While most systems in the cloud are secure by default, many professionals make assumptions that leave them vulnerable or stop them from using the cloud to its fullest potential.
Security Assumption #1 – The cloud is inherently unsecure
This easiest assumption to handle is the idea that the cloud is inherently unsecure. Companies that are considering the cloud have been led astray by the misguided opinion that the cloud is more open to attack than on-prem architectures. Honestly, if I had to choose between most IT departments that are responsible for a multitude of issues and responsibilities versus a cloud provider’s dedicated team of security professionals, I know which one I would choose. (hint: the latter.)
On top of that, you will find that cloud providers have adopted a “private by default” stance when dealing with data or access to systems. Their business hinges on the idea that they are a trusted partner with security at the forefront of their minds. If there is even a hint that they are doing things without security as their number one consideration, they will lose customers instantly.
Security Assumption #2 – Cloud providers handle all of your security
This assumption is basically the reverse of the first. Instead of assuming that the cloud is unsecure, admins assume that the cloud providers will handle ALL of the security for their environment. This is a dangerous decision. Regardless of who you choose to host your cloud infrastructure, they all follow what is known as the “shared responsibility” model for security.
They will take full responsibility for the physical data centers by controlling access and managing bandwidth and hardware. Anything that occurs above the hypervisor is your responsibility. This includes encryption, authentication and authorization, least privilege and more. If you are unsure if it is your responsibility to secure something, find out instead of assuming that someone else will handle it. All providers have very clear documentation on this topic, so search the web for “shared responsibility” and you will have clarity.
4. Assuming Experience On-Prem Translates to the Cloud
There are similarities between administering private datacenters and using the cloud. Many companies use a “lift and shift” approach where they take their existing infrastructure and build a replica in the cloud. While this works, you are more likely to waste money and continue to perform at the pre-lift and shift level which misses opportunities you were pursuing.
How to avoid making mistakes as a cloud architect
1. Understand the cloud through training
The largest benefits of moving to the cloud are only unlocked if designs are changed, and you take advantage of services that are only offered or possible in the cloud. Even if you have 20 years of experience in IT, knowledge of these services and architectural models do not pop into your head fully formed. There are two main ways in which you can address this problem.
Developing your knowledge, skills and abilities in cloud computing is critical. Training provides guided paths of these new technologies with expert help just a hand raise or unmuted microphone away. While some small portion of what you learn in a class may not be pertinent to your specific job, it’s important to familiar with services and skills outside of what you require today. These classes also help to prepare you for certification exams, which are in high demand in the current job market.
Recommended classes to develop these skills
This class teaches you to launch servers, autoscaling groups, and elastic load balancers (all the necessary components for elasticity at the server level).
Nothing beats hands-on experience. Providers offer the ability to create personal accounts, and some companies offer sandbox environments for experimentation. If that’s not an option for you, as long as you remember to terminate any resources you generate in a timely manner, the cost of experimentation is low and can offer true hands-on experience with new products and technologies. The GK Polaris Accelerate subscription offers hundreds of hands-on challenge-based labs in a safe environment.
These mistakes can be resume-updating events if you are not careful. Take the time to learn the skills of a cloud architect and both your career and your employer will benefit.
Jeff Peters is a systems engineer, cloud architect, and technical trainer with over 20 years of IT experience and a current focus on Amazon Web Services and Microsoft Azure. He holds several MCSEs from Microsoft along with Professional and Specialty certifications from Amazon. Jeff resides in Metuchen, NJ with his wife and two sons, who all roll their eyes when he gets overly excited about technology.