In this blog post, I will talk about topics not covered in your cloud certifications exams! I will discuss building infrastructure that treats UX as a first-class citizen.
Before we begin talking about UX, we got to apprehend what the word "Infrastructure" entails. Infrastructure has many facets; I will categorize them into two categories:
Core components
Supporting components
These areas are essentially everything that powers an application and it looks something like this.
Looking at diagram [1.0], we see core components are:
Networking
Servers
Storage
These are the foundational pieces to have any application available online.
The scary part is the supportive services since all of these services have one or many tools, lots of expertise required and individual evolution.
💡 The supporting systems are not organized in any particular order. Typically they co-exist and evolve as your team grows.Just so you get an impression of the options available in these areas, look at the Cloud Native Cloud Foundation landscape below.
That begs the question: How can we construct infrastructure that caters to our users, engineers and applications, without creating Frankensteins?
Since this is a broad question, I will try to answer it from a very high perspective.
I firmly believe that a big reason why we have so many Platform engineers and many other teams that collaborate to maintain large-scale infrastructure is that we don't tame the complexity soon enough. We refactor code all the time to support our software, but we don't refactor infrastructure. It almost feels like infrastructure is in a continuous exponential growth in complexity as companies grow.
It's time to take a step back. We have more tools than ever. Yet, we still create inflexible, non-resilient systems that are ultimately marching towards death. I don't care if you have five-nine availability if it will require the entire platform teams to not sleep in case of a disaster because they aren't sure how to do a complete failover. Don't get me wrong; I am not blaming the engineers here. I am blaming the overall ideology that lacks UX principles in infrastructure.
What are the goals of an infrastructure utopia?
Repeatable
Scaleable
Resilient
Available
Secure
Refactor-able
Understandable
Autonomous
One way to measure if your system is in the Utopia spectrum is to ask, "how long does it take a new engineer to contribute to your system?"
Please don't at me with "Complex systems require more time!". Though it is partially true, it is crucial to distinguish decaying system design from beautifully evolving systems.
Principles that should be used on an atomic level to accomplish a grand harmonious system:
1- Code-ability:
Codify your infrastructure; reduce manual work to an absolute minimum.
Reviews: code must be formatted, linted, and standardized. When looking at any piece of the infrastructure code, it must look exactly like any other infrastructure code.
Use a domain language, and favour declarative language.
Practice all coding practices we use to build business software.
2- Gaining more knowledge
Teams must be very familiar with specialty areas to the level of experts: This doesn't mean to be like Netflix and never hire juniors. It means that you grow your team under the supervision of domain experts and evolve your team.
Allow ownership of services. This way, teams care about it.
3- Refactor
As you gain more knowledge, you must refactor your infrastructure with this new information.
Audit your environments, and retrofit them only to have what's deemed to be there (Less is more).
Ensure that you remove any system that causes friction. Yes, if the load balancer you are using doesn't allow automation. Go to your boss's boss's boss and explain why refactoring will mean more money!
Don't be afraid to be wrong; we refactor our thoughts, believes and perceptions too!
4- Usability testing
Here we must treat engineers as external users; we design the systems that elevate their workflows and reduces resistance.
Asks users to interact with your infrastructure through build systems, self-service portals, etc.
Take notes of what they do and what difficulties/confusion they face when dealing with areas they aren't familiar with. Feedback is the most valuable thing!
Prioritize usability over performance. If your engineers can't operate it, you already failed!
5- Establish rail guards
Your system should have rail guards that don't allow destructive actions.
Don't limit critical areas to a selective few. Provide access reasonably but make sure your rail guards will protect/notify even the most experienced team members. We all make mistakes.
Practice chaos engineering; Ultimately, you want to build self-healing resilient systems! So test your environment!
6- Confirm before investing
Back to the usability aspect: Always invest in making sure that anything in your environment serves both the business users and the engineers equally!
Guarantee that the team is happy and satisfied by usability, performance, and each subsystem's growth before investing heavily in it.
Try to minimize emotional and financial investments in subsystems as much as you can. The larger the investment, the more complex the replacement, which leads to more costly maintenance, refactoring and risk cost!
7- Build a culture that doesn't settle.
Use Merced's slogan, "The best or nothing."
Build a culture that is critical and diverse
Observe juniors and newcomers to the team closer than seniors; These are the groups that provide trust in your work when you see it picked up and employed quickly.
8- Automation
This piece will be a blog post by itself where we will talk about CI/CD UX and how to utilize build systems in a way that is a breeze. There is a reason why there are bazillion CI/CD platforms there!
I hope this blog post has inspired you to think of infrastructure as another user-facing system and make you spend more time in making it a more friendly territory.
Cheers!
If you liked this post please share it with your friends, or tweet it!
Yorumlar