devopsy.kinsta.cloud

Category: KubeCon 2019

  • Best of 2019: Implementing Message Queue in Kubernetes

    Best of 2019: Implementing Message Queue in Kubernetes

    As we close out 2019, we at devopsy.kinsta.cloud wanted to highlight the five most popular articles of the year. Following is the fourth in our weeklong series of the Best of 2019.

    The adoption of Kubernetes as enterprises’ tool of choice is increasing very rapidly. Consequently, the architectural consideration and operational requirements to support production environments have gained increasing attention. A major challenge to consider when planning a scalable microservices architecture (MSA) that is orchestrated by Kubernetes is how to manage the heavy traffic of messages in the system.

    After migrating from the monolith architecture to a microservices architecture or setting up a new MSA, each microservice holds its data model and is disengaged from the rest of the system. When scaling, it is observed that a project can grow to hundreds or more microservices, and the messaging traffic can become enormous in systems that generate millions of messages a day. Hence, there is a need for a new robust communication between the microservices to be established.

    Using Point-To-Point connectivity such as REST to solve the communication gap in Kubernetes can end up creating a complicated structure between the services. A consequence of this is the need for comprehensive maintenance by the development team each time service requirements are changed. This is where a messaging queue system comes in handy to take care of the messaging challenge in MSA and Kubernetes. Each service communicates with one focal point (message broker queue) in its own language and the message queue system is in charge to deliver the messages to the services which are waiting for it.

    To build a well-managed messaging solution for Kubernetes, the message queue system should be native to Kubernetes, support the relevant messaging patterns, robust and secured. Being native to Kubernetes is a critical parameter to achieving a healthy system in Kubernetes. It includes a simple and fast deployment to Kubernetes (and not outside of the Kubernetes cluster), low DevOps maintenance and well connected to Kubernetes ecosystem for logging, monitoring and tracking.

    Hybrid Cloud

    A hybrid cloud solution enables enterprises to make use of both on-premises and public cloud services. An advantage of a hybrid cloud is the flexibility it offers–allowing workloads to alternate between the two environments when capacity and costs change, for example. Sensitive workloads and data can be hosted in the private cloud or on-prem while less critical workloads are hosted in a public cloud. Regulatory requirements for data handling and storage can be provided in the private cloud. A commercial advantage of public cloud services is cost, both in terms of CapEx and OpEx, as the scalability it provides allows an organization to pay only for the resources it uses. Deploying message queue in Kubernetes provides the technology that allows the hybrid clouds to smoothly and transparently connect and interact.

    Use Cases

    There are many use cases for message queues. The message queue needs to support diversified messaging patterns, enabling flexibility in creating different use cases.

    Here are some of the common use cases a messaging queue system should support in Kubernetes.

    Multi-stage Pipeline

    The synchronous pattern is used when we need to process the messages in a coordinated way in a workflow. Pipeline use case allows processing messages in a sequence between services. Each service can be considered as a stage, and the message passed between all the stages in a sequence. In some cases where the message is lost or cannot be processed (for any reason), the dead-letter queue mechanism takes the message and process it in a pre-defined way.

    Job/Task Distributed Queue

    The A-synchronic pattern is used by some producers to many consumers when we need to distribute tasks/jobs between workers. In this use case, there is no need to coordinate between tasks. Each service is pulling messages from the queue to process it. The sequence of processing the messages is not important as each worker takes the task from the queue and process it in his own time.

    Figure 1: Tasks/Jobs Distributed Queue.

    Stream

    The A-synchronic pattern is used when we need to stream data from many external sources (big data, IoT) and process it in a dedicated service such as database, pipeline, machine learning, storage, etc. This case typically aggregates many producers to a small number of consumers. The order of messages is not important, but the delivery guarantee is important.

    Pub/Sub Real-Time

    The A-synchronic pattern is suitable for cases of a small number of producers sending real-time data to many consumers. A service acting as a publisher sends a message to a channel where a set of services subscribe to that channel and get the messages.

    Application Decoupling

    Connectivity between services such as edge, API, databases and storage act like a router, and message order is not important; timeout and sync between producers and consumers are important.

    Ease of Use

    One key feature of the microservices architecture is its ease of use. Deploying it saves your organization time and money by unifying development and operations workflows. The message queue system needs to be easy to use as well. Its ease of use and DevOps’ friendliness should minimize the need for dedicated experts and, at the same time, accelerate development and production cycles. While considering this, it’s important to ensure support in high volume messaging with low latency, efficient memory usage and fundamental messaging patterns (real-time pub/sub, request/reply and queue) are not compromised.

    Gradual Migration to Kubernetes

    When IT professionals evaluate the significant advantages of using the Kubernetes environment, they cannot ignore the operational requirements necessary to maintain the revenue-generating monolith infrastructure. Legacy systems also contain the processes and data related to the on-going business and are crucial for the service contingency.

    To support a gradual migration that keeps the business operation, the Kubernetes message queue must enable connectivity between the old and new environments. A bridge is required to connect the legacy side to IBM MQ, TIBCO, MSMQ or Kafka (just to mention a few popular enterprise solutions), to the Kubernetes message queue that allows a seamless bi-directional transposing messages between the services in the legacy monolith environment and the microservices-based deployment in the Kubernetes environment.

    The bridge installed in the legacy environment is “listening” to the MQ on behalf of the relevant services in the Kubernetes environment, ensuring the designated messages are transferred from the monolith to Kubernetes and vice versa. This bridging capability enables gradual migration by implementing a step-by-step replacement of components from the old environment or the creation of new services that can still connect with the legacy resources.

     

    Figure 2: An example of gradual migration from MSMQ on the on-premises environment to AKS.

    To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

    — Lior Nabat

  • The Foundational Era of Open Source

    The Foundational Era of Open Source

    Contrary to popular belief, software is not eating the world. Open source software is eating the world. This was very apparent at the Linux Foundation’s KubeCon + CloudNativeCon event recently in San Diego. Driving this phenomenon is what I call the Foundational era of Open Source.

    This Foundational era of Open Source has replaced what I call the Big Brother era that came before it. The Big Brother era itself replaced what I call the Cathedral and Bazaar era of open source.

    The Cathedral and Bazaar Era

    I first became involved in open source software in the mid-90s. I might have dabbled and used open source software before that as I searched for free tools using WAIS and Gopher. But I really became aware when I founded TriStar Web, an early hosting company. Back then, web server software came in basically three flavors: 1. Netscape Web Server, from the people who brought us the Netscape browser (it was my choice); 2. Microsoft’s Internet Information Server (ISS), which was that era’s version of the Evil Empire; and 3. Apache (I don’t even think there was an Apache Foundation yet), the open source web server that was taking the web by storm. Besides being free, it was a lot more flexible and capable than the other two.

    During this time there was, of course, another open source software vying for dominance in the market. Something called Linux developed by a guy named Linus Torvalds was taking on all of the giants that had their own flavors of Unix, while Bill Gates’ Windows was fighting it out against IBM’s OS/2, which he also developed.

    Yes, those were heady days for open source software. I call those days the Cathedral and Bazaar days of open source. The Cathedral and Bazaar, of course, refers to the collected essays and then the book of the same name by Eric S Raymond. It, more than anything else, laid out for me the power of open source software and the tensions between the worlds of open source “free as in beer, free as in freedom” versus closed source software.

    Let’s be clear, the open source software world would not exist but for the lessons learned, battles fought and wins and losses of this era.

    Anarchy, Chaos or Freedom?

    In those days you had people such as Dr. Richard Stallman advocating for free, open software that you could use, distribute and modify as you wish. There were intellectual debates over the pros and cons of various open source licenses (Apache, GPL, etc). Most of all, it was very difficult to bring open source software into the enterprise. No support, no training, no SLAs … how was the enterprise to use open source?

    Nevertheless, open source prevailed—sometimes on sheer quality, other times on the love of developers who relished in the freedom of open source. It became a force in the tech world. Companies such as Red Hat, Suse and Canonical capitalized on Linux. Other companies tinkered and experimented with models to try and become commercially successful with other open source tools. By and large, it was a rough go, but some did succeed.

    In my own case in InfoSec, we had great open source tools including Snort, Nmap and Nessus. The folks at Tenable did stop developing an open source version of Nessus, but they still offered a free version of it. Yes, it was a great time in open source—or so I thought.

    The Big Brother Era of Open Source

    Sometime in the early 2000s, we passed into what I call the Big Brother era of open source. This was characterized by almost every open source project having a managing or controlling commercial entity dictating its direction and code. While this didn’t happen with Linux, it became the de facto standard.

    Companies were spun up by the founders of an open source project and while the project itself remained open, it was owned lock, stock and barrel by the commercial entity. The company would sell training and support and in some cases open core versions of the software with “freemium” modules available for a price. Eventually, SaaS-based, hosted versions of the open source software would be another business model companies used to monetize open source.

    Issues regarding who owned the code, who contributed to these projects and where the community fit in often caused conflicts. But by and large, the open source communities counted on the benevolence of the Big Brother to make sure the open source versions of the software remained viable.

    In retrospect, though, this era stifled contribution by other entities: Who would want to contribute code to an open source project for the benefit of the controlling entity? Many companies forked their project so they could control their own versions, resulting in the Balkanization of many of these projects, with the community being the big loser.

    The Foundational Era of Open Source

    Between 2012 and 2015, though, we passed into a new, modern era of open source software that I call the Foundational era of open source. Open source projects were given to community-owned, non-profit foundations to manage and nourish—organizations such as the Linux Foundation, the folks behind Cloud Native Computing Foundation and the Continuous Delivery Foundation; Cloud Foundry Foundation; The Apache Foundation; and the Eclipse Foundation (one of the early entrants, even if IBM did come to dominate it) took over the stewardship of many open source projects.

    This has ushered in a truly golden age of open source software that has seen open source become the dominant form of software in the world. The Foundational era of open source has flourished for several reasons. For one, now multiple commercial entities can contribute code without worrying that it is for the exclusive benefit of just one company. What’s more, these foundations have a mix of vendors, practitioners and large enterprise users that really do allow for the democratization of open source at levels not seen before. Also, there is a process of incubation to graduation that these projects are put through that help them evolve and grow.

    Not to be underestimated is the new generation of developers who have grown up with open source and only want to work in open software. They are putting their influence into practice. Instead of sneaking open source in the back door, they are knocking down the front door with it.

    There are other reasons, but the result is that open source today is now in use at well over 90% of enterprises and it is by far the dominant form of software. It is leading the way in the move to the cloud and in business transformation, and it is literally changing the world.

    Long live open source.

    — Alan Shimel

  • And the Builders Shall Inherit the Earth: The Democratization of IT

    And the Builders Shall Inherit the Earth: The Democratization of IT

    The democratization of IT is happening, and vendors need to recognize that if they want to survive

    Just back home from KubeCon/CloudNativeCon in San Diego, which can only be called a force of nature. I was joined there by more than 12,000 other folks to discuss, listen and learn about all things cloud-native and open. Once again, I was blown away by the passion of and buzz generated by this community. What is driving it? I think I figured it out: The developers and builders shall inherit the earth. It is the democratization of IT.

    What I mean is that a fundamental shift has taken place in the IT world. Developers, architects and builders are in such high demand and are now the alpha predators of the food chain. They are the ones demanding and deciding what tools they use, how they build and what infrastructure they use.

    Smart vendors are recognizing this and penetrating large organizations by giving these builders the tools they absolutely will love working with. In many cases, these tools are free and open to use in non-enterprise versions. The vendors also have DevRel teams and marketing that cater to these builders and developers, rather than traditional marketing and sales.

    The fundamental shift is that for the nearly 30 years I have been in IT, the mantra has been to talk to the “decision-makers”—the CTO, CIO, and VPs who approved and paid for purchases in IT. Entire marketing strategies and sales were built on this. Lead generation campaigns focused on reaching executives, while salespeople vied for position by taking these people to dinner or golf and shmoozing them. Content was created that spoke to the executive class. Very few folks tried to focus on the practitioner; after all, they didn’t make the decisions; they didn’t hold the purse strings.

    That way of doing business has all changed. Yes, there are some dinosaurs out there who don’t hear the meteor speeding down just yet. But by and large, companies that are thriving in this new era of open solutions, open core and free software are doing so by following a new way: They cater to the developer/builder class. They listen to what this group wants and provide it to them. After that, they make sure tools evolve to meet the needs and wants of the builders. They have figured out that when they deliver delight, these people will tell their organizations that these are the tools they want to use.

    I heard Shlomi Ben Haim, co-founder and CEO of JFrog, call this the “democratization of IT.” This, along with DevOps and the cloud, are the megatrends driving transformation. But I also spoke to dozens of other vendors at the show. Maybe they didn’t call it that, but they instinctually recognize it.

    The world wants software-based everything. The people who are building the infrastructure, writing the code, testing, deploying and securing this software are demanding that it be open, free and cloud-native. They want to use it for a while before they will invest in the paid, enterprise versions and functionality. But once they do, their organizations buy in.

    The buying cycle starts off with the use of free software—maybe an employee whips out a credit card for a small monthly fee to purchase the SaaS version. But it ends with an enterprise purchase.

    The democratization of IT is going to work its way through our entire ecosystem. Content is going to be catered not to the executive suite, but to the practitioner. Lead generation programs aren’t going to focus on CXOs, but on people who will actually use the product. Sales strategy and tactics will reflect this as, too. More dev relations, less golf.

    Another driving force of this market is the new generation of people who are building and deploying. They don’t have an allegiance to the whales of yesteryear. They are fresh and willing to try new things if it gives them the functionality they want. Don’t give me that millennial, “OK, Boomer” crap, either.

    These folks work hard, and they are passionate about what they are building. They want open. They are used to having free tools and they are the new boss.  Maybe not the same as the old boss, but they are not fickle and want to choose the tools they work with. They will not be dictated to by a generation of folks who built during a different time with a different way of doing things. Successful vendor organizations need to realize that and work with these people.

    Of course, executives still set budgets and have to sign off on larger or more expensive purchases. They will need to be satisfied. But increasingly, it is not going to be the vendor who does that. They will rely on their builders and their developers to choose their tools and products. If you are a vendor and are not operating this way, look up to the sky because you just may see a large fireball coming your way.

    I, for one, think this is a good thing. It is time for the democratization of IT. Let the builders inherit the earth.

    — Alan Shimel