When staring down the DevOps path, you have no lack of tools to help you pave the way. But there’s one you’ve probably never thought of, maybe even never heard of, and it’s time to expand your horizons. Please allow me to introduce you to the world of connection brokers.
When I say the words “connection broker”, what comes to mind? If you’re focused on devops, potentially nothing. Typically, connection broker technology is limited to the realm of virtual desktop infrastructures (VDI) and, outside of that world, most people don’t think they need one.
But with the correct connection broker, you strike a balance between control and automation in your DevOps environment, as well as roll the management of servers, applications, and desktops into a single platform.
A connection broker manages connections to hosted desktops, providing users with seamless access to the tools they need to get their jobs done. It ties the pieces of your data center together, providing a single pane of glass for managing and accessing the desktop capacity in your hosted infrastructure.
As VDI workflows evolved, so did connection brokers. No longer just for connecting users, connection brokers became tools that create and delete virtual desktops, as well as systems that monitor user access. The connection broker logs information about who is using each desktop, and for how long, so you have a comprehensive picture of desktop usage in your environment.
To summarize, using connection broker pools and policies, you manage the desktop capacity in your datacenter, who has access to these desktops, how long they have access, and what happens to the desktop when the user disconnects, logs out, or is idle. You can share desktops among users, ensure that you always have the required desktop capacity based on user load, and monitor when you need to expand your data center or burst into the cloud.
That last point is true because, ideally, your chosen connection broker works across multiple hosting platforms, allowing you to build a hosted desktop environment that encapsulates legacy virtualization platforms like VMware, while allowing you to invest in upcomers like Ubuntu OpenStack and leverage public clouds like Amazon Web Services, Microsoft Azure, and Google Cloud Platform.
Now replace the word “desktop” with a generic term like “resource” and abstract all the provisioning, connecting, and monitoring tasks. Can you start to see how a connection broker fits into a DevOps environment?
If not, the road block is likely with the term “connection broker”. It leads you to believe the software only brokers connections. Fair enough, however, a comprehensive connection broker is an automation tool, and maybe even an orchestration tool. Most brokering solutions include a component that runs on the remote resource, allowing you to run configuration scripts on the resource after it is created.
Put that all together and a connection broker becomes a portal where developers can request access to the exact type of application, compute, etc., that they need, even creating that resource on-demand. Operations defines the different types of resources that are available, providing templates (for example, AWS AMIs) that developers (and the connection broker) use to spin up the resources.
Yes, I concede that there’s a lot more to DevOps than managing resource capacity and connections. You have to deal with networks, storage, application installation, and a host of other components.
Luckily, there are several tools that can help with these tasks. A connection broker simply complements these tools, providing last-mile features for resource access for developers and users.
In other words (and this may sound vaguely familiar) – Connection brokers, they don’t define your DevOps culture, they make your DevOps culture better.
By Karen Gondoly
