So your company is moving to the cloud, that's cool,
but how does it affect YOU?
How things work on-prem
When applications are on-premises, developers typically have little say about the infrastructure their applications run on. The choice of languages and frameworks may be set in stone, and applications are more likely to be monolithic.
Even with the increasing adoption of DevOps practices, there may still be a significant divide between application developers and the infrastructure/operations team - your deployments may be automated, but setting up a new server probably isn't.
How things change in the Cloud
The Performance Pillar of the AWS Well Architected Framework includes these Design Principals:
- Democratize advanced technologies: Make advanced technology implementation easier for your team
- Use serverless architectures
- Experiment more often
- Consider mechanical sympathy
This isn't just true of AWS, the ability to quickly spin up new resources, initially for experimentation and then all the way to production, is a feature of all Cloud platforms.
The architecture of applications built to take advantage of running in the cloud can be radically different to what you've been previously building, and while you can deploy an ASP.NET core API to AWS Lambda (for example), how it behaves in that environment is significantly different to running it in IIS.
AWS provides a NuGet package (see Amazon.Lambda.AspNetCoreServer) that makes it easy to do this. It works pretty well, but instead of one copy of the API serving many clients you have many copies of the API each serving one client at a time. There are also limitations in areas like file upload and download (which vary depending upon whether this is being used with API Gateway or an Application Load Balancer).
Become a Cloud Developer
For Leading EDJE I've worked on a number of cloud migration projects, as an architect, developer and cloud engineer. I've seen the difficulties that developers can face getting up to speed with the cloud, and the miscommunication that can occur between application and infrastructure teams.
It's more important than ever for developers to understand how their applications run when deployed and not just on their machine when developing. This requires developers to have an understanding of the Cloud platform that's being used and it's features and quirks. It's also important (this has always been important) for developers to be involved in supporting applications all the way through their lifecycle including production support.
Training and certifications
Hopefully, if your company has decided to move to the cloud they've recognized that there's a skill gap and have a plan for training. If so, make sure you take advantage of it - even if you don't use it immediately, it shows a willingness to learn that looks good at review time. If unfortunately your company hasn't got a plan in place, or they are limiting who has access to the training to a select few (perhaps they think developers don't need to know the details), then it behooves you to still do what you can to learn about the cloud.
This unfortunately may mean that you need to learn about the cloud in your own time, and I recognize that not everyone has free time to spend on this self-study, but if you do there can be many benefits for your career.
If your company doesn't want to make use of your new found cloud skills, there are lots of other companies that are looking for them.
Studying for a cloud certification is a good way of getting an overview of a cloud platform. There's a variety of free and paid training (much of it inexpensive), and you should also go hands-on and sign up for a free trial of the cloud platform your company is using so that you can try some things out.
Mechanical Sympathy
“You don’t have to be an engineer to be be a racing driver, but you do have to have Mechanical Sympathy.” – Jackie Stewart, racing driver
If you don't understand how the cloud platform works, then you can build an application that runs in the cloud, but you can't build a cloud native application that makes efficient usage of cloud resources.
Cloud Native is an overused term that has multiple different definitions.
The Cloud Native Computing Foundation has a heavy focus on Kubernetes and Linux, but when I talk about it I'm thinking more of what's described in this Azure Cloud-Native overview, with a combination of managed services, containers and serverless.
New applications you build in the cloud can take advantage of services provided by the platform, but you can only do this effectively if you understand the strengths and weaknesses of those services. It may make sense to decompose your application into microservices or even smaller units of work and use messaging to decouple processing.
The implication of this is that as a developer you need to be more involved in architectural decisions even when you are working on relatively small applications. You will hopefully have someone in your organization setting guidelines for Cloud architecture, but each application has different needs.
You may have the opportunity to get involved in provisioning the infrastructure using Infrastructure as Code tools like Terraform, CloudFormation (AWS), Azure Resource Manager or Cloud Deployment Manager (GCP). If you can help to build the infrastructure you are far less likely to be held up waiting on another team to do the work or to have difficulties communicating what you need.
Infrastructure as Code may be foreign and new to you, but it's the best way to really understand how the building blocks in a cloud platform fit together.
Organizational resistance
A cloud migration is a journey for a company and it may require changes that not everyone is ready to accept.
As a cloud developer who learns how the cloud platform works, you can be in a position to influence how your company adapts and this can be a great career opportunity. That may put you at odds with those who oppose change, but having a deep understanding of the platform allows you to educate those around you and overcome some of those difficulties.
A change of role?
For much of my career I was a Java developer and then an application architect specializing in Java. I learned about AWS while I worked on my first Cloud project and found myself splitting my time between architecting/developing parts of the application, and building out the infrastructure using CloudFormation.
Personally I enjoy the mix of all these different roles, but you might find out that you have an affinity for building cloud infrastructure. The relatively new field of Site Reliability Engineering can be a good fit for those with a development background.
You owe it to yourself
I firmly believe that Cloud platforms are here to stay and will become the dominant deployment platform for the applications we all develop. Even those organizations who do not want to use a public platform are likely to adopt technologies where infrastructure can be provisioned on demand.
So, if you consider yourself "just a developer" you might want to rethink the boundaries of what that means.
Oldest comments (0)