DEV Community: Ilango

Production-grade AWS architecture [Part 4]: Networking

Ilango — Mon, 04 May 2020 14:58:17 +0000

Networking in AWS is such a huge topic that cannot be explained in one blog post. I'm also not going to cover every service under it's roof. Networking in AWS spans multiple services. Each has its own set of features that provides an incredible level of flexibility for your needs. This flexibility exists to support any requirements that you might have.

There is a problem with this flexibility though. It's easy to make mistakes by misconfiguring your network. These mistakes will cause things to not work or lead to security and compliance issues. Knowing this, AWS puts forth what's called a Shared Responsibility Model. The responsibility of security and compliance of your web applications and services is shared between AWS and you. AWS takes care of security "of" the cloud — data centers, hardware, software, networking. You take care of security "in" the cloud — data, encryption, operating systems, firewalls etc.

Regions and Availability Zones

Amazon Web Services is built on top of a global network of datacenters. These datacenters are segmented on two levels — regions and availability zones. Regions are geographic locations where a cluster of datacenters are located. There are 24 regions as of this writing. Availability zones (AZ) are physically isolated datacenters in the same region. There are usually 2 or 3 AZs per region with a global total of 76. AZs within a region are connected by low-latency network connections. This global infrastructure is the backbone that provides scalability, reliability and performance.

Why are these details important?

Depending on your use-case, you might want to run your services in multiple AZs and even multiple regions. By being available on multiple regions and AZs, you can provide higher availability for your customers. This could also be for handling failovers. Or for reducing latency by being available close to your customers' physical location. So when you're starting on AWS, you'll have to pick region(s) based on your requirements.

You should also know that new services will be made available only to a few regions first. For example, EC2 is available in all regions because it's one of the oldest. AWS Comprehend is not available everywhere because it's relatively new. It's a good idea to check if the service you want to use is available in the region your deploying. Check out the region table to see which services are available in the regions you want.

Networking services on AWS

The following are the networking services available on AWS:

Virtual Private Cloud (VPC)
Elastic Load Balancer (ELB)
Route53 (DNS)
API Gateway
CloudFront (CDN)
DirectConnect
PrivateLink

Please note that each of these services has a lot of functionality to cover every use case under the sun. I won't be explaining all of these services in this post (or any future post with one or two exceptions). AWS documentation is pretty good for explaining what these services are. For most use cases, you'll be using 1 through 5.

A note on VPCs

VPCs are such an important part of your infrastructure. A VPC is a logically isolated network that is built on top of the AWS global network. Each VPC is self-contained and unless configured to do so, cannot communicate with the public internet. VPCs give you a lot of controls to configure a network for your needs. Internet Gateways, NAT, ingress and egress controls, access control lists and more. A lot of compute services on AWS — EC2, Lambda and ELB — heavily relies on VPCs to function.

For this reason, AWS automatically creates a VPC in every region when you create your account. That said, you should never use the default VPC in a production environment. This is because, the default VPC is set up to allow you to quickly provision resources. They are not designed with a production environment in mind.

When setting up your production infrastructure, you should setup and configure a separate VPC. In fact, you should setup a VPC for each of your development environments — dev, staging and production. How you setup your VPC depends on your requirements but there are a couple of architectures that can get you started.

We will go in-depth into these architectures in the next post.

Understanding software entropy

Ilango — Thu, 30 Apr 2020 01:47:03 +0000

Do you know what I think the coolest law of physics is? It's the second law of thermodynamics.

The total entropy of an isolated system can never decrease over time, and is constant if and only if all processes are reversible.

Put in normal person words, disorder will always increase over time unless you do something about it. The laws of thermodynamics talk about heat and how it affects matter. But when it comes to the second law, entropy specifically, it's universal.

Think about all the problems you've faced in life. They always seem to just show up but it takes effort to solve those problems. If you're a super lazy person like me, you know that when you're lazy for too long, life just becomes shit.

This is why I think that entropy and the second law of thermodynamics is the coolest law of physics there is. Because it's not just a law. It's a mental model for solving problems. It also applies to software development.

Imagine that you take a box of puzzle pieces and dump them out on a table. In theory, it is possible for the pieces to fall perfectly into place and create a completed puzzle when you dump them out of the box. But in reality, that never happens. Why? Quite simply, because the odds are overwhelmingly against it.
— James Clear

Imagine you're starting a software project. In the beginning you want to get features out the door as quickly as possible. You're not thinking about clean coding practices, or have future maintenance and tech debt in mind. You want to get to generating revenue fast. At this stage, your entropy is low because the system is new. Facebook even had a phrase that became quite popular:

Move fast and break things.

Let me tell you that there is nothing wrong with this mindset. In fact, it's required for your business to get off the ground. Because your users won't care about your "zero tech debt" (is that even a thing?) or that you've obsessively organized your codebase. Your software has to work.

But you won't stay in this position forever. There will come a time when you have to start thinking about code quality and start clearing out your tech debt. So why is entropy relevant here? Because as time goes on, the disorder in your codebase(s) will start to increase. This will happen when you've added features, bug and hot fixes and when more team members are contributing to the codebase.

What does entropy in code look like?

When the entropy in your code is high, you'll start seeing effects of it:

Making changes to your system gets harder. This happens so slowly that you will never see it coming. Eventually, new features and bug fixes will break existing ones. It starts off with one hot fix here and a workaround there. It's even possible to snowball this effect — more and more "hackish" code to fix existing ones.
Your team will start developing "information silos". There will be specific people with absolute knowledge of parts of the system and changing it will need "their expert opinion". It'll be harder for the team to contribute because they won't know the nuances yet.
The software breaks in unexpected places. Fixing simple issues takes valuable developer time. Because, unlike other types of engineering, software is a series of logical assertions. Once these assertions starts breaking, it'll lead to multiple interpretations of how the system functions. Some of these interpretations might even be incomplete because you don't see the full picture.

And as the law states, entropy can only increase. You can never decrease entropy in a system. Note that this is different from tech debt. You can reduce tech debt but you can never reduce entropy. With effort you can keep it constant or decrease it's growth.

How to mitigate entropy?

There are three ways that I know of.

A well defined code review process. When your team members are reviewing each other's code, there are lesser chances for your assertions to break. It'll be easier for others to interpret your code the way you intended. How does this look in practice? You're having healthy discussions with your reviewers in a pull request. It's important to do this publicly so others can see it and can act as a reference in the future.
Setting aside time for iterations and refactoring. This is easier said than done, however. Refactoring takes time and effort and will have no business impact in the short term, whatsoever. This is the reason development teams usually don't spend time refactoring. It's harder to sell the impact when effort doesn't affect revenue.
This is by far the hardest. It takes a change in behaviour and thinking. Being mindful of your assertions and how they could be misinterpreted goes a long way. Shaping the constraints of a feature and clearly defining them also reduces the chances of misinterpretation. This will slow down development a bit, but you're saving yourself and your team future headaches. And in the long run, it actually saves time.

Entropy is not something we actively think about during development. But it plays a major role in how you build software. Although you can't decrease entropy, it's possible to reduce the growth and it's effects. What process do you follow at work to mitigate entropy? Is there a process you follow that I should know about?