Micetro: The API to your Multicloud

Managing DDI in a Multicloud Environment

When I think of Multicloud, I consider the entire on-premises solutions as well as the public cloud solutions to be part of that Multicloud architecture. It’s not just multiple clouds being managed by separate teams in silos, but rather, in an ideal state, it’s moving towards simplified operations of multiple platforms with teams that are less and less siloed.

No matter which cloud and on-prem solutions you go with you’re going to have multiple underlying services that are managing your DNS and DHCP. In AWS you may be using Route 53 for your internal and external DNS, along with maybe some Microsoft or BIND internally. In Azure, you could be using Azure DNS for your external DNS, and Microsoft for your internal DNS services. While on-premises you could be using a combination of BIND, Microsoft DNS and DHCP snap-ins, and perhaps a spreadsheet keeping track of your IP information. You can see where things are starting to get complicated. In a previous blog I talked about using abstraction to gain centralized visibility and management, which is one great way to simplify operations and move towards sustainable networking. Because of that abstraction, we’re able to also use a central API for easier automation as well. Automation through a central API, like the one provided by Micetro, is the concentration of this blog.

A Central API for Site Reliability - Or Really Multicloud Reliability

A central API is integral to simplifying operations because it allows you to build a more consistent and therefore reliable infrastructure. With Site Reliability and consistent workflows, you can reduce the fragility of your DDI system.

Many people make the mistake of thinking automation is about saving time, and while that might be a byproduct, it’s actually about creating reliability. For example, if you create a workflow for deploying a new server, you can be sure that every server is created in a consistent manner with no human error, including where it goes to get DHCP and DNS information. That’s a simple example, but as you bring in larger orchestration models, you can see how this leads to more consistent networks, or even entire sites. This is part of the idea of Site Reliability, as originally coined by Google.

You can go beyond simple deployment workflows to consider troubleshooting and reporting as you move towards Site Reliability in our mutlicloud environments. The idea of the CI/CD (Continuous Integration/Continuous Delivery) in DevOps lets us continually improve our networks to move beyond traditionally fragility.

Create Once and Use Everywhere

Creating workflows for several different underlying services adds to the complexity, and actually goes against the consistent ideal of automation. With an overlay solution, there is just one API and then you let the overlay communicate with the underlying services. Now, no matter where you’re deploying that server, as in the example used above, you can use the same workflow. Even if those underlying services may change as you make different decisions about the underlying services, you’re still able to use that central API, in some cases without any disruption to the services offered to our employees and customers.

Sustainable Networking Using Micetro

I love the idea of Sustainable Networking. It doesn’t mean that we can just continue to do and use the same things over again. It means we can continuously improve the way we do things, without having to rip-and-replace our platforms every time we want to make improvements. Micetro enables not only network engineers, but also DevOps teams to embrace the model of the CI/CD feedback loop to be more agile in the network while also reducing fragility.

For more information on automation with Micetro, check out how this Global Edutech company overcame infrastructure sprawl https://menandmice.com/resources/case-studies/automation-devops