A personal outlook on my changeover — and adaptation — from traditionally managed-servers into AWS infrastructure

Image source: https://serverguy.com/cloud/aws-migration/

Transitioning from any aspect into another in life can be daunting, and at the same time exciting. In IT, there are plenty of scenarios where this fact is actually applicable. One obvious example of homogenous transition is the ever-trivial version upgrades. From upgrading your dependencies to upgrading your runtimes, the range of problems you can face is tremendous. But as an attached sidecar, you almost always run into prodigious learning curves, where the return(s) of investments are positive when you think in terms of the progression of your career and as well as the advancements of your organisation’s systems. On the other hand, the range of problems might be tied to your organisational practices, and the quality of the upgraded constituents. The latter is one thing that we cannot control, and focusing on the former, a revealing consideration comes to my mind from the book “Software Engineering at Google” (read the online version here): it’s about the concept of “sustainability”. Sustainability of code, it says, depends on your ability to change — safely — what’s necessary for the lifetime of your code (this temporal factor is something that is forgotten quite often). If it’s otherwise, necessary and sufficient steps are required to cater for this without much delay.

“Your organization’s codebase is sustainable when you are able to change all of the things that you ought to change, safely, and can do so for the life of your codebase.” — Winters et al. (2020). Software engineering at google: Lessons learned from programming over time. O’Reilly Media.

This article, however, is not about what I called “homogenous transition” in the paragraph above. That is, it is not about upgrading versions of the same technology, but migrating/moving-on to a different technology — call it “heterogenous transition”. The obstacles you face might be different in nature, but depending on the quality of your decisions, the return(s) of investments can be plenty. It might also depend on the scale of your transition, i.e., you might be migrating one component of your architecture or you might be moving your whole architecture (with changes) into a different platform (via an IaaS, for instance). Or, it might be you, who’s migrating from one organisation to another, where the systems are totally different. And this, my dear reader, is the topic of conversation here.

It all starts with a decision.
I come from an organisational background where we managed our own servers for a large part of the organisation. There are plenty of reasons emphasised in general for managing your own servers, but one that has a bit less weight on is based on one party that’s involved in our contracts: the client. Client’s requirements and demands vary from domain to domain, and some clients do not prefer offloading server management to a third party (may it be privacy, security and/or for some other personal reasons). This was the reason for us managing our own.

With the passage of time, the organisation evolved into more modern approaches, like containerising an application and orchestrating the containers. But still, those container images and orchestrators were deployed into our own server clusters: infrastructure managed by our own support teams.

The personal journey in question starts with my decision to look for a better career opportunity. This decision was not least affected by technical parts of the organisation, but for other personal reasons where this article won’t trod into.

Transitioning from one style of infrastructure to another have benefits and costs. It’s just a matter of weighing out the two and choosing either the former or the latter. Easily said than done, though.

Facing it for the first time.

This was what I saw for the first time: except the “Recently Visited” section was empty and the “Account” section was different. Can’t remember which “Region” it was by default.

Some time ago, I stepped into the AWS universe. And this was not for a bootcamp or a training program. It was real-world application development. It was diving head-first into application development without knowing much about the end of the pipeline (deployment). Quite often development and deployment goes hand-in-hand, where decisions in one affects the other. For example, if you write code that accumulate too much garbage, your deployment aspects need to cater for that; otherwise, the applications would cease to run after some time.

In summary, I knew how to write code alright, but didn’t know how to write code to be deployed in this new infrastructure.

Did this transition affect in terms of development? Well, I cannot say that it did not — since it will rule out the fact that you must always be mindful when and where your application is going to be deployed. But, almost all of the business logic implementations were left in-tact just like we used to do when we were hosting our own infrastructure. I will try to some of the idiosyncrasies I saw in this transition in the next article.

Author: Dasun Pubudumal