Search for a command to run...
I used to be a .NET developer. Nowaways, I am a DevOps solutions architect with a focus on Azure and Kubernetes.
I also love productivity topics, especially when it comes to doing more with less of my time. I'm also a daddy, so time is a limited resource for me.
No comments yet. Be the first to comment.
I'm going to share all my secrets with you
Using a pull-request workflow
This is the guide I wish I had
Connecting your GitHub Workflows to Azure AD using OpenID Connect
In this post, I’ll walk through the essentials of configuring an AKS cluster to use Argo CD with an NGINX Ingress Controller. Pre-Requisites You’ll need: An AKS cluster. Here’s a Gist I use to create a simple cluster. Helm 3 Azure CLI A Custom DNS/A...
With the rise of new virtualization technologies using containers, people are starting to think more and more about using microservices in their organizations. It’s a topic that has been getting a lot of attention. Many top technology companies have attributed some of their recent success to microservices. Some of these companies include Netflix, Amazon, Uber, and Spotify. Every day these companies use hundreds of microservices to power their products and stay nimble.
What’s a microservice architecture? It is the practice of building an extensive application using multiple services working together. A business capability is developed end-to-end and encapsulated in a small service, i.e., a microservice. Each service also runs on its process and communicates with other services using RESTful or queue-based protocols. All the database access, business logic, and any other infrastructure code are encapsulated in one service to fulfill a business need.
We have gotten better at providing meaningful experiences for our users as an industry. Users see the value and request more features. However, our applications reach a point of diminishing returns. The Law of diminishing returns teaches us that we will see diminishing returns for the amount of effort placed on development at some point in time.
So how does a company continue to innovate and stay agile as products get larger? One solution is microservices. With this approach, you focus on developing business capabilities autonomously. Instead of orchestrating a significant release to offer new features, a new business capability can be added by simply adding a new service. Eventually, you create microservices that can be developed, tested, deployed, and managed independently of other parts of the application.
The world of microservices is so rich already that it’s easy to get enamored with its tools and technologies. We may try to shortcut success by purchasing platforms and tooling centered around building microservices. One of the best ways to reduce the risk is to educate ourselves on the principles of microservice and the role of DevOps within it. So here are three reasons why you should start with DevOps.
Conway’s Law states that a company will design systems that reflect how the organization communicates. For instance, if your system is split into a front-end tier, a back-end tier, and a database tier, there’s likely a front-end, a back-end, and a database team. So if your organization is structured in a way that does not mirror a set of independent and autonomous services, then it probably won’t be capable of building microservices. Could you develop small services with large horizontal teams? Sure. But The additional complexity could quickly swarm units with micro-tasks to support a microservice architecture.
If you don’t start with DevOps, teams can become less independent than before. Productivity can grind to a halt because development teams can’t deploy their code. Quality Assurance teams could become bottlenecks because all the untested code hits their backlogs at once.
Defect count would soar because issues are not “reproducible.” Developers would have to develop with many services running at once because of the lack of automated testing. Developing in this environment would be highly cumbersome, especially with new services and more team members. Developers would have to interrupt each other constantly to help others troubleshoot and run their services.
Microservices architecture is a natural progression of embracing DevOps. A successful DevOps practice results in continuous integration & delivery, automated testing, and applying monitoring and telemetry. There are many more benefits of DevOps, but to touch on a few:
Teams build and package their services without relying on other teams/departments in the company. Teams release often and frequently without impacting other groups.
Teams find out quickly when there’s a regression in their service. Teams are encouraged to write unit tests because that’s the quickest way to get feedback.
Issues are quickly narrowed down to a microservice, reducing the constant need for escalations to get problems resolved. Teams become responsible for supporting their service. Teams get encouraged to experiment and improve their services while measuring their performance.
