In this article, we’re not just going to focus on power efficiency and carbon footprint; that’s just the discriminant. Sustainability is not just about optimization. We are not going to take pre-engineered services and then try to ensure they’re sustainable. We will look at the inception phase because you will learn that 75% of the impact you can have on sustainability is during the inception phase, not the optimization phase. So when you want to optimize the carbon footprint and reduce e-waste from your digital services, you want to look at the kind of resources you will consume. 75% of the impact you can have on all that is before you even start your first line of code during inception. We’re going to see that.
When you’re going to engineer something, one of my wishes is that more engineers look at the impact that they can have on the overall ecosystem. So how do we make sure that this ecosystem is sustainable in itself? We want to have a proactive approach. We don’t want to be reactive anymore.
Why do we want that?
Many APIs in the ecosystem are either dying or are close. This has a tremendous impact on the business because it’s costly to maintain and very difficult to use.
You tend to have some zombies that are still running on servers and are barely used. Sometimes, they have one or two consumers and are seldom used, cluttering the overall ecosystem.
APIs are slowly dying from Conway’s Law.
Some APIs are not well designed. This clutters the overall ecosystem.
Conway’s Law tells you that any structure you produce is a mirror of your communication system. So if you have a team that works well together and is always working on the same thing most of the time, you will have some monolith. If you have distributed teams working on many different things at certain times and integrating, maybe you’ll have some kind of microservice architecture. The problem is that because of the communication structure, and because teams rotate a lot, they don’t communicate well. For example, you build a lot of depth APIs that connect to other APIs that are legacy APIs. Or you have a legacy structure and are building on top of it. And things get a bit clunky. So at some point, you want your ecosystem to be invulnerable.
If someone asks for a change, it is not possible anymore, as the original structure is missing. You will have to make many different choices that will clutter the system even further. So that’s why we need to have a different approach.
- Avoid inconsistent or cluttered design.
- Avoid the lack of product or service vision resulting from your teams not being aligned on what you are building.
- Make sure that whenever you produce something, an API that you add to the ecosystem means something; it has a proper impact, and you know exactly what it will deliver out there.
- You want everyone to be aligned on the value that you’re going to deliver. You want them to collaborate.
- Ensure that the APIs are well documented because you may not support these APIs forever. But we want them to last as long as possible.
- For the ecosystem to be sustainable, we want to ensure that whatever we add doesn’t rotate too often and needs to add value for a certain time.
APIs are slowly dying from tech obsolescence.
Most APIs are also running on technology that may be obsolete in a few years. You may have heard of technologies like AMF/LCDS, SOAP / WSDL, XML, RML, etc. These are now outdated. Now, more and more consumers do not want to consume these APIs. We are using REST and RESTful services.
We still have these zombie technologies, meaning they’re not completely dead, but we still have to manage them in the company. So, we have to be careful in our design choices for the deployments that we want to have in the future.
Keeping these APIs “alive.”
You might want to consider the cost of keeping all these APIs alive. The ones running on old technologies, the ones not properly designed, and it’s a bit clunky to use them. Most of the time, we are going to use anti-corruption layers. And that’s the allegory. You are raking in this modern world, and you want to survive, and you want to interact with the legacy world. But the problem is that it’s full of zombies, and you want to have this anti-corruption layer and not get beaten and corrupted. You want to work with that.
Testing for API diseases.
An API disease is something that will slowly lead the API that you’re designing to a zombie state. And you want to avoid that for sustainability.
So, you may want to ask yourself,
do I have a lack of vision in my API? Do I have a lack of coherence or lack of records? If I lack these things, maybe the value I deliver out there is not properly identified? So maybe the value I deliver is not at the level that I want it to be. It will slowly decay as well. Do I have a hard tech dependency? Do I have a hot coupling with other APIs that may be legacy APIs? Do I use non-standard protocols? Do I have a lack of renewability in my overall ecosystem? Your API may be well used, but the overall infrastructure you’re running it on is not that optimized. This means that you have over-engineered it or are not running it on the cloud or with shared infrastructure.
In a system, maybe at some point, you want to ask yourself, is it well-tailored for the service I deliver? Do you have an under-used interface, server, or service? You have to be careful because this will impact the cost of maintaining your APIs.
What is sustainability? Sustainability is at the crossroads of many different things. So we will aim for social impact in our APIs. Whatever you deliver out there, it’s for certain users. You want to make sure that it will help them in some ways that will help their life; it will help the work. And you’re going to have happy users.
Once you have that on your side, it makes sense for your business. You have something equitable, meaning that you deliver a service out there, and it’s well-received. Most of the time, when you have that, you find balance, and you’re happy with that. But that’s not enough for sustainability.
Environmental impact of APIs.
Environmental impact means that whenever you produce an API, it will use server resources. Even if you use a server on the cloud, it’s going to use power. It will also need manufacturing resources. Whenever you take space in a data center, you’re taking space from someone else. Most of the time, because your APIs are running 24 hours a day, seven days a week, you need to have new racks and servers; manufacture new servers and physical hardware. That has the most impact on the planet. You might want to know that two-thirds of the environmental impact you can have is on the pre-manufacturing and manufacturing phase of the hardware. It’s not during the run phase of your APIs.
The best impact on sustainability is to ask, “Does my API need to be out there?” Once you know that, you can run your API on hardware that is already existing so you can improve the reusability of the hardware. Once you have a balance between social impact, business impact, and environmental impact, that’s where we aim for sustainability. And that’s what you should be aiming for. You should be sure that it will be valuable for users when you engineer something.
Sustainable API Engineering
You have to be careful about the cost-efficiency. It has to be beneficial for your business. You have to see how much it will cost you to maintain these APIs and what will be the revenue?
On the other hand, you have to look at resource renewability. How much of the hardware can you reuse? How much of the old code can you reuse? How much of the legacy system is in there? The development phase also takes a lot of resources because you will need developers. You will need to upskill them. They will need the latest laptops also to develop your API. So you have to be careful about that.
You’re not just engineering solutions anymore. You have to think about the bigger picture.
You have to be careful because if it’s just cost-efficient and you have resource renewability, you might have a useless API, but it’s still viable. You have to be careful because renewability might be costly and not sustainable if you have just the value delivery and resources. So you want to aim for sustainability.
What about Flexibility, Evolvability, and Performance at Scale?
Flexibility is all about how fast you can change the implementation. So when implementing APIs at scale, you want to make sure you can change the components quickly. You’re still going to grow, so you want to ensure that you’re not going to be stopped at some point or blocked.
Evolvability of the system. How fast can you deliver a new feature? Performant: You want things to be efficient and delivered fast.
A vision for overall coherence
We want to ensure that we are not cluttering the system. You want to control the growth of your system. You also want to ensure that you have a vision for the overall occurrence when designing APIs. So you want to be impact-driven. For them to be useful, you want them to be reusable. You want to do a bit of domain-driven design.
Keep it sustainable and simple!
