The process of building software usually begins with a set of requirements; As engineers, we are trained to find the most efficient way to solve these requirements. Then, we figure out how to adjust and scale the software based on the usage and reliability needs of users.

This process is cyclical, even Sisyphean. As the software is used and the business grows, the product must be improved to meet new needs or requirements. Therefore, engineers must “refactor” the code, then test it and deploy it again.

Refactoring, in the context of building software, refers to the process of making small and safe changes to the code to improve its performance, maintainability or other aspects without altering its overall behavior. It’s like polishing and optimizing the existing codebase. The Prime Video engineering team, for example, faced the challenging task of refactoring their serverless architecture to use long-running, containerized services, which required changing the way the software was structured and managed.

Martin Fowler, the famous software developer, said it best, “[Refactoring’s] essence is applying a series of small behavior-preserving transformations, each of which is “too small to be worth doing.” However, the cumulative effect of all of these transformations is quite significant. By doing them in small steps you reduce the risk of introducing errors. You also avoid having the system broken while you are carrying out the restructuring — which allows you to gradually refactor a system over an extended period of time.”

I have recently heard some exciting stories about changes afoot in the way software is built and managed with the potential to break this cycle. Some organizations are refactoring distributed cloud services into monolithic applications, or even transitioning from the cloud to a data-center environment. Many organizations going through the digital transformation process are interested in the cyclic transition after breaking from monolithic architecture, though some barriers remain.

Thanks to a technique called “infrastructure as code,” wherein engineers manage and provision computer infrastructure through code and automation rather than manual processes, this journey of refactoring the infrastructure layer is a possible descriptive task. But it’s important to note that this refactoring process still takes a lot of time and effort to design, implement, test and deploy the changes safely, so that they don’t cause any problems with the system.

In the case of the Prime Video engineering team, their goal was to continue providing excellent video content and application behavior to users while making significant changes to the way the infrastructure was set up. They manually ported or “recompiled” the infrastructure by altering the way it was defined in code, moving from using short-lived Lambda functions to using longer-lasting Elastic Container Service (ECS) services.

Considerations for Architecture Shifts

Moving to a different architecture, like the Prime Video team did, comes with its own set of things to consider:

• Productivity
  • Different compute interfaces require different levels of effort and maintenance. For example, serverless setups need less maintenance, whereas long-running servers need more attention.
  • Some architectures need more code to get started, which can affect how quickly engineering teams are able to get the software up and running.
  • Simplifying a complex system of small services (a microservice spaghetti) can make it easier to work on without relying too much on the cloud. 
• Reliability
  • Simplifying a microservice spaghetti can make it easier to test and observe, which improves the software’s reliability.
• Cloud Security
  • When you change the architecture, you may need to adjust how the system defends against attacks as the attack surface will change.
  • Roles and permissions (IAM roles) and network setups may also need to be updated, and sometimes even application-level code may be affected.
• Cost
  • Each cloud service has its own pricing structure, which must be taken into account when making architectural changes.

As a software builder myself, I have come across various best practices for re-architecting systems over the years — and I’ve even led some of these efforts myself. However, I have often found the task to be repetitive, requiring extensive documentation and scattered across too many programming frameworks and paradigms. My main concerns were that such changes take time and always come with the risk of something breaking. So, I often wondered if it was the right way to allocate engineering resources.

Changing architectures is a complex process that involves cross-team collaboration and communication between application and infrastructure teams, even for simple changes. A solution that would consolidate these application and infrastructure requirements did not exist… until today.

Enter Wing Cloud*

Founded in April 2022 by Elad Ben Israel, Creator of AWS CDK and Shai Ber, former VP R&D at EquityBee* with deep roots in scaling cloud infrastructure and creating widely-used developer tools, Wing* is a new programming framework meant for the cloud.

The benefits of Wing, in my opinion, include:

• Increased Productivity: Unifies application and infra code, infra is generated by a compiler and less code needs to be maintained by developers.
• Cloud Security: Compiler can reduce the attack surface and generate the least-privileged IAM permissions and network topologies by application code.
• Cost Reduction: An engineer can observe the cloud workloads and re-compile the architecture from one compute resource to another by the metrics of the observed workload.
• Faster Development Iteration: Wing can simulate a cloud environment locally and enable a faster feedback loop.
• Cloud Portability: Retains app code and the infrastructure can be recompiled to a new cloud target.
• Service Portability: App code stays, and the infrastructure can be recompiled to a new service target (Example: In-memory queue, Kafka queue, AWS SQS).
• Distributed Programs: Lowers the barrier of using cloud-distributed infrastructure by inferring requirements from application logic.

Since its inception, Wing has assembled a team of 10+ engineers across the U.S. and Israel, and Europe and has planted the seeds, I believe, to create a meaningful open source in the cloud infrastructure space.

At Battery, I get excited when founders and entrepreneurs approach complex problems with first-principles thinking, simplicity and clarity. Elad, Shai and the rest of the Wing team bring a wealth of knowledge from their time spent at Amazon, Microsoft and Equitybee* and, I believe, understand how to bring clarity to cloud engineering’s most complex problems. I look forward to seeing how they continue to innovate.