What exactly does a cloud engineer do? What skills should they have? How should you improve your competencies while working in this position? Jarek Śmiejczak from Clearcode, the “one-man band” within the IT industry, answers many questions about the topic.
Let’s start from the beginning. When did you start your career in IT and where did it all begin? How did you get the idea to enter this industry?
My story is very conventional :) When I was 7 years old I got my first computer which was an Amiga 600 with a monitor and a beautiful black joystick. As if this happiness wasn’t enough, next to the computer was a whole pack of 3.5″ floppy disks full of games. I got into it and lost myself completely. I became interested in programming much later. As a teenager, I started to create my first GUI programs in Borland Delphi, using an object-oriented dialect of the Turbo Pascal language.
You started programming professionally at the age of 19. Where did you first start? Do you remember your first job interview?
My first significant job was creating websites in a small interactive agency in Lodz. The interview itself went quite well because I presented some pieces of code from my high school days. Although the quality of this code left a lot to be desired, it was enough to get me a job as a PHP programmer and start my adventure in IT.
What were you doing at the beginning of your professional career?
Originally, my beginnings were with a more “holistic” approach to web development. Working on advertising campaigns often required one to quickly pick up new skills and adapt to the often changing conditions and client requirements. One could say that it was a considerable and long-lasting lesson in humility towards the results of one’s work. Of course, in the beginning, it wasn’t such a completely independent job and on my way I met many great people who helped me in this process.
The multitude of problems that arose — from the wrong text color on the page and the list of articles not loading, to the heart-wrenching HTTP 500 error — meant that I had to learn many things: either aspects of MySQL or changes in the latest version of PHP and how it affects the Apache configuration. The reality of this part of the industry required a wide (though not necessarily deep) range of skills and practical problem solving, all according to the principle “create code so that the invoice is paid” :) .
You became interested in the DevOps role relatively quickly. Why this choice?
I find DevOps as a profession fascinating mainly because it focuses on many aspects and stages of software development. Supporting the team in delivering results to the customer gives me a unique feeling of satisfaction. This is something that came with time, but I think that there is no turning back from this path :)
Creating any major application-deployment pipeline requires knowledge of programming languages, but also the ability to communicate, both with technical people (mainly programmers) and with people who focus on business aspects. This area interests me a lot, especially the real impact each line of code has on the world and the people in it.
PHP, Python, and cloud engineering. They refer to you as a “one-man band” :) Did you have any specific plan for developing your skills and career path? And how did you develop and improve them?
I can honestly admit that gaining knowledge came organically and in the beginning I didn’t have much of a specific plan other than to follow my passion. I met many people who offered a helping hand when I really needed it and inspired me to commit even more.
Along with the responsibilities that came my way, I started to become interested in ways to organize my work, starting with just getting things done. Working with clients meant that along with the hard skills, the soft ones had to be developed.
How did you end up at Clearcode? Please tell us about your beginnings in the company.
One July afternoon I noticed an offer from a “small” company in Wroclaw, which dealt with systems such as web analytics. I applied for the position of Python/Django developer, with which I already had some experience, and after a very nice interview, I got an offer and moved to Wroclaw.
I joined a team of really cool and very technical people who learned alongside me how to review, test, and at the very end, deploy and monitor applications. We’d often make mistakes and learn from them, e.g. by introducing post-mortem meetings, creating more layers of tests and adding more metrics to applications.
While working at Clearcode, you noticed AWS, which was just starting to gain popularity. Why did you make that choice?
The teams I’ve been working in have quite often been thrown in the deep end. We started with thousands of requests per second but now we’re dealing with millions of requests per second and only the future will tell if we’ll stop at that number or not. It became obvious that with this kind of activity and demand, we had to be able to adapt dynamically to our clients’ needs. In one of my first projects, a client passed us a piece of code that was hosted on AWS. And while that choice wasn’t entirely conscious, AWS as a platform turned out to be a lucky shot and opened the door for us to scale solutions for a company that wouldn’t have been able to do so without AWS as it would have meant getting their own server room, which they wouldn’t have been able to afford.
During your time at Clearcode, you had your first professional opportunity to work with AWS. What did that work involve?
I had the opportunity to be involved in writing Python code in Fabric that deployed an application, then with the team migrating the infrastructure definition from Puppet to Ansible, eventually Terraform appeared as well. On the same project, we started with 150 EC2 instances dedicated to answering thousands of incoming requests from platforms, which in AdTech are called ad exchanges. The AWS API allowed us to automate many aspects of managing such a project.
We’d often make mistakes and learn from them, e.g. by introducing post-mortem meetings, creating more layers of tests and adding more metrics to applications.
What does a cloud engineer do? What skills should they have?
There are many very basic skills required to get your foot in the door for this position, but I will list the most important ones:
- Knowledge of key services from at least one of the cloud providers, which allows you to deploy applications. For example in AWS it is EC2/ECS/EKS.
- The ability to program in one of the popular languages (Python, Golang, Ruby, etc.), to the extent of being able to write scripts that automate deployment.
- Proficiency in configuring systems and deploying applications (CI/CD).
- An understanding of patterns related to cloud architecture/microservices and knowledge of where and when to use them. In the case of AWS, there are educational paths that allow you to learn some of these issues and apply them when using AWS.
- Having good communication skills — e.g. a pragmatic and analytical approach to obstacles.
- Architectural knowledge of creating secure solutions and awareness of weaknesses in protocols that the application uses.
- Performance optimization — e.g. observability and distributed tracing.
- Deep understanding of how monitored application works, which metrics to use, and how to create readable dashboards. Also those that allow people to view business metrics.
- Documenting infrastructure/ architectural decisions and being able to explain their impact on the project.
- An understanding of ways/patterns for cost optimization of deployed solutions.
- Sharing knowledge with the development team.
What are you working on currently? What technologies do you work in?
I’m working on code development in Terraform, as well as Ansible, Python and process automation in Azure Pipelines. This includes the entire portfolio of AWS services, from ECR to Redshift.
Moreover, I participate in solving problems that arise during application development and usage of cloud services by developers (e.g. how to connect to the database, which information is worth logging, etc.), I also participate in the process of creating application architecture and documenting the decisions made.