In my previous role as a systems engineer one of my responsibilities included managing hardware. If a power supply failed on a server, I had to drive to the data center to replace it. It didn’t happen often, but when it did it was certainly a pain to do so. The great thing about being a cloud engineer is that there’s no hardware to manage.
Becoming a cloud software engineer was an arduous journey, personally. I had some experience coding from college and side projects, but that’s about it. The thought of writing code at an enterprise level made me feel uneasy, but I feel like I’ve come a long way since. Now that I have been in this role for a few years I discovered a few qualities that may restrain a person from excelling in this difficult, yet exciting new industry.
1. You have a difficult time learning new concepts quickly.
If you’re in the tech industry at all, chances are that you’re already comfortable learning new things. In the on premise world, you could be learning how to convert your company’s databases from SQL Server to Oracle or migrating your firewalls from Juniper to Cisco. However, these things typically takes a lot of time and requires a lot of planning and coordination.
In the cloud world, everything moves very fast. Part of the reason is because the people that work in it operate with the mindset and culture of DevOps. This allows the companies that practice it to release new features at a staggering pace and where code changes can be deployed to production within a matter of hours.
2. You’re not a T-shaped person.
A T-shaped person has a good foundational knowledge in many things, but is an expert in at least one. In a traditional on-prem technology department there are engineers that specialize in specific areas such as networking, linux, windows, security, databases, and so forth.
In the cloud, resources are easily accessible and can be deployed within a matter of seconds. If you need a load balancer, you don’t need to spend weeks waiting for a data center engineer to rack it or a network engineer to configure it. You can simply deploy your own at the click of a button. The same goes for any other resource. However, this benefit comes with a price. You must have sufficient knowledge about the service in order to properly configure it. That is why having a T-shaped skill set is such an important part of being a cloud engineer. You are, essentially, all of these roles in some form or another.
3. You don’t have a ‘cattle over pets’ mindset.
The ‘cattle over pets’ analogy is commonly used to explain the mindset DevOps engineers have when designing their architecture. In the cloud, it’s all about designing infrastructure with the expectation that everything will fail at some point and how to recover from that failure with the least downtime possible.
If an application team is receiving failing health check alerts for one of their servers, automation should exist to terminate that unhealthy server and deploy another in its place. With the ‘pets’ mentality, the app team could potentially spend hours analyzing logs, re-imaging, and re-configuring that particular instance. Who wants to do that?!
4. Automation is the furthest thing from your mind.
Automation helps reduce the chances of error that comes with manual intervention. Teams can utilize a declarative configuration management process to create a consistent deployment process. The consistency allows teams to easily refine their their pipelines to reduce the number of defects introduced and release feature enhancements. In general, more automation leads to more consistent deployments with less errors and wasted billable hours by engineers.
5. You’re not comfortable working with code.
If you’re going to be working with in the cloud you better be comfortable working with Infrastructure as Code (IaC). I’m not saying it’s bad to fiddle around with things in the console. It’s great if you’re first learning a new service or if you’re doing a proof of concept (PoC). However, you shouldn’t have anything in your production environment that hasn’t been deployed using an automation pipeline or isn’t stored in version control.