devopsy.kinsta.cloud

Tag: microservices

Essence and Motivation

May 11, 2020
IBM Looks to Drive Edge Computing

IBM today at its Think Digital conference launched an edge computing initiative anchored around an IBM Edge Application Manager, through which a single administrator can manage up to 10,000 nodes.

Hillery Hunter, vice president and CTO for IBM Cloud, said IBM Edge Application Manager is based on the Open Horizon open source software originally developed by IBM that is now under the auspices of LF Edge, an arm of The Linux Foundation focused on networking and edge computing platforms. Open Horizon makes uses of machine learning algorithms to automate the management of fleets of edge computing platforms.

IBM also launched IBM Telco Network Cloud Manager to orchestrate both virtual and container network functions. IBM Telco Network Cloud Manager is built on top of an instance of Red Hat OpenShift, which is based on Kubernetes, and Red Hat OpenStack Platform.

Finally, IBM is making available a range of edge-enabled applications, including IBM Visual Insights, IBM Production Optimization, IBM Connected Manufacturing, IBM Asset Optimization, IBM Maximo Worker Insights and IBM Visual Inspector.

Like most IT vendors IBM sees the rise of application workloads on the edge as an opportunity to drive adoption of hybrid cloud computing. In the case of IBM, all of these offerings run on the Red Hat OpenShift platform.

IBM also announced the IBM Edge Ecosystem, which brings together independent software vendors (ISVs) and IBM partners to craft edge computing solutions. Additionally, IBM launched the IBM Telco Network Cloud Ecosystem, which is more narrowly focused on edge computing platforms deployed for telco-focused environments such as a wireless 5G network.

IT vendors participating in those initiatives with IBM include Cisco Systems, Dell Technologies, Juniper, Intel, NVIDIA, Samsung, Packet & Equinix, Hazelcast, Sysdig, Turbonomics, Portworx, Humio, Indra Minsait, EuroTech, Arrow, ADLINK, Acromove, Geniatech, SmartCone, CloudHedge, Altiostar, Metaswitch, F5 Networks and ADVA.

Edge computing will undoubtedly force organizations to embrace DevOps more aggressively. Managing thousands of edge computing platforms will require not just higher levels of IT automation infused with machine learning algorithms, but IT teams will also need to be able to deploy, secure, update and manage applications distributed across thousands of endpoints.

IBM, of course, is not the only IT vendor eyeing the edge computing opportunity. The challenge IT organizations will face first is building new classes of latency-sensitive applications running in near real-time that will be built mainly using microservices. Once those applications are built, organizations will then need to update them continuously within the context of a highly scalable IT management framework.

Naturally, some organizations will prefer to rely on external IT service providers to rise to that challenge while others will continue to build and manage their own applications and infrastructure. Regardless of the approach, the level of scale and complexity at which IT is being applied is about to reach a level that once would have been unimaginable. Not only will more applications run in near real-time, those applications will be integrated and share data with batch-oriented applications running in the cloud and local data centers. The challenge is finding a way to automate the management of IT at scale without requiring organizations to rely on manual processes, for which there are simply not enough IT professionals available to manage.

May 5, 2020
Software Testing: The Comeback Kid of the 2020s

The past 15 years have been rough on software testers. The rise and fall of outsourcing, Agile growing from a manifesto to a movement and ever-shrinking release cycles have all taken a toll. By 2011, Albert Savoia walked on stage at the Google Test Automation Conference (GTAC) dressed as the Grim Reaper and declared testing dead. Since then, the emphasis on the “automation” part of “test automation” has fueled demand for Software Development Engineers in Test (SDETs) and left many testers wondering if they must learn programming to save their jobs.

If you look at how frequently people are searching for “software testing” on Google, the trends seem to suggest that the profession is, if not dead, at least flatlining.

However, I think the times are a-changin’. The pendulum will be swinging back—to the point where software testing could be the comeback kid of the 2020s. Sounds crazy, I know. But consider some developments that could turn things around.

Developers Don’t Want to Bear the Testing Burden

On Agile development teams, the party line is that unit testing is essential. It’s the most efficient way to expose implementation errors as they’re introduced. You can feasibly cover each function/method when you test at this level, plus when a test fails, you know exactly what function is broken. Moreover, having a suite of effective unit tests establishes a safety net that alerts the team whenever changes break previously-verified functionality. Those are just a few of the reasons why unit testing forms the foundation of the Agile test pyramid.

But, if you talk to developers in a casual setting, the truth starts to come out. Unit testing requires a lot of work, and they’re skeptical about whether it pays off. Just skim through a few of the 2.5 billion results returned by a Google search for “Is unit testing really worth it?” to get an idea of some of the issues.

Unfortunately, a seemingly endless amount of work is required to ensure that unit testing delivers long-term benefits as a regression testing safety net. Developers are committed to progression testing, not regression testing. Although developers on Agile teams usually write unit tests to check new functionality, few keep them up to date as the code base evolves. As the team moves on to another sprint, these tests become regression tests. Then, little by little, they start failing—but developers have moved on. The number of working unit tests at the base of the Agile test pyramid erodes, as does the level of confidence the test suite once provided.

In fact, data from our internal studies on financial instructions across EMEA shows that as an iteration ends, unit tests cover about 70% of the new code. After a few iterations of code getting extended, refactored and repaired, the original unit tests provide only about 50% coverage of that original functionality. This drops to 35% after several more iterations, and it typically degrades to 25% after six months.

Is Unit Testing Doomed?

Ultimately, developers don’t have the time or desire to keep these tests current over the long term. Unit testing has been a best practice for more than 20 years, yet despite waves of unit test automation tools (including one created by Albert Savoia not long before he declared testing dead), unit testing remains a thorn in developers’ sides. Does that mean we give up the benefits of unit testing altogether? Not necessarily.

In order to take on unit testing per se, testers would need to understand the developers’ code as well as write their own code. That’s not going to happen. But, you could have testers compensate for lost unit test coverage through resilient tests they can create and control. Professional testers recognize that designing and maintaining tests is their primary job and that they are ultimately evaluated by the success and effectiveness of the test suite. Let’s be honest, who’s more likely to keep tests current, the developers who are pressured to deliver more code faster, or the testers who are rewarded for finding major issues (or blamed for overlooking them)?

Another option is to consider new testing approaches that achieve unit testing benefits for today’s most popular development architectures—but without requiring knowledge of the code. Enter microservice contract testing.

Microservice Contract Testing: The New Unit Testing

Interest in microservices (the blue line on the graph below) has been rising rapidly since 2015. In fact, it seems to be on the exact opposite path from software testing (red line).

This rise is hardly surprising. From the architecture perspective, there are significant benefits to microservices. Initial forays into service-oriented architectures (SOA) were a huge step forward in enabling reuse and flexibility. Business logic formerly implemented in monolithic applications was freed and released as isolated independent services, which were loosely-coupled and highly-distributed.

Microservices take the decoupling and granularity to new levels. Business logic is now implemented in the smallest, most discrete units possible. Functionality that would have once been a single service is now distributed across tens, or potentially hundreds, of microservices, each of which can be independently developed and deployed.

In addition to enabling unprecedented agility and scalability, this extreme decoupling opens up promising new options for testing. With the initial waves of services and APIs, API tests had little choice but to pass through a fairly broad set of business logic, which was likely implemented through multiple units of code (e.g., functions).

If an API test failed, there was no clear pointer to what specific code function needed to be fixed. That required unit testing and/or additional debugging.

Now, with each microservice implementing an extremely focused unit of business logic, you know exactly what code is broken when an API test fails. Why spend the time and effort on unit testing if you’re already getting the benefits from something that’s considerably less painful?

You might be thinking, “Testing hundreds of independently-evolving microservices is just going to present a different pain.” Correct. Each integration point is a potential point of failure, and testing all the possible integrations is a logistical nightmare—so don’t. Instead of testing how each microservice interacts with all the other microservices it touches, perform contract testing instead.

Very basically, contract testing helps both microservice consumers and providers ensure that they’re meeting expectations in terms of message format and data. The microservice consumer adds a contract that specifies expected request and response pairs for its various interactions with other microservices. Each contract is used to create a virtual service that the consumer can then test against. If the consumer’s changes result in incorrect/unacceptable request messages, they’ll be alerted immediately by a contract failure message triggered from the virtual services.

On the flip side, the microservice provider can use the same consumer-specified contracts to ensure that their own changes don’t break the functionality which consumers depend on. If the actual provider response suddenly fails to meet consumer expectations, they, too, get a rather clear and telling contract failure message.

The beauty of this approach—even beyond the fact that neither consumer nor provider ever has to stand up the whole spider web of interconnected and independently-evolving microservices—is that you get very specific unit-level failure information without burdening developers. As soon as testing moves away from the code level to the API level, it doesn’t need developers doing it. You certainly don’t need developers to deal with the maintenance, and you really don’t even need them to set up the test. Instead, the task can be delegated to people who view testing—not development—as their profession. We call them testers.

Looking Beyond Unit Testing Is Essential for Ensuring a Positive User Experience

Nevertheless, hyperfocusing solely on unit testing of any flavor can leave you blind to many critical issues. For example: Does every step of the end-to-end transaction work as expected—from whatever mobile or browser interface the user happens to have, through the backend (which might interact with custom/legacy applications, packaged applications, mainframes, databases, third-party services, etc.) and back to the user? Will these same transactions perform acceptably under a sudden increase in demand? If the user exercises the application in ways that the developers didn’t anticipate, will the application respond in a reasonable manner, or at least fail gracefully?

The answers to such questions lie beyond the horizon of the testing performed by the typical Agile team, which rarely extends beyond unit testing and a little integration testing.

However, as organizations invest millions in digital transformation initiatives, this doesn’t cut it. Maximizing that investment requires a flawless user experience from start to finish, 24/7. Professional testers thrive on exposing the glitches that developers tend to overlook but that would cause a CIO to cringe.

I’m confident that software testing will surge in importance in the 2020s if we commit to expanding its scope and effectiveness, which will ultimately elevate its business value. As the pendulum swings back, testers can’t expect to just hang on for the ride. Willingness to jump on the momentum of this decade’s trends—for example, stepping in to solidify the foundation of the Agile test pyramid and embracing new practices such as microservice contract testing—will be essential for navigating the turnaround.

April 24, 2020
Google Names CloudBees App Dev Partner of the Year

Google this week named CloudBees its 2019 Cloud Technology Partner of the Year for Application Development at a time when the rate at which application workloads are heading into the cloud is expected to accelerate.

Beyond the Jenkins continuous integration/continuous delivery (CI/CD) platform on the Google Cloud Platform (GCP), CloudBees also makes available a software-as-a-service (SaaS) edition of Jenkins X, a CI/CD platform optimized for Kubernetes, along with a CloudBees Software Delivery Management (SDM) service for managing DevOps processes.

François Dechery, chief strategy officer for CloudBees, said CloudBees chose to partner with Google at that level versus other cloud service providers because Google made it clear it would partner at both the technology and business development level. In addition, given Google’s long history with Kubernetes, it also made sense to leverage existing Kubernetes expertise, he noted.

In the wake of the COVID-19 pandemic, more application development work will be moving onto cloud platforms that can be remotely accessed more easily by development teams, he added.

In some cases, organizations will opt to self-manage those platforms or rely on a traditional managed service provided by a third-party IT services firm. However, Dechery said there also has been a significant increase in the number of organizations willing to consume a DevOps platform such as Jenkins X as a SaaS application, as long as the IT environment is proven secure. SaaS platforms are now a mainstream element of any enterprise IT environment, said Dechery.

Many of those decisions will be predicated on what degree of abstraction any organization is comfortable with as IT platforms become both more complicated and diverse, added Dechery, noting one thing that attracts organizations to Jenkins X is that it abstracts away the complexity associated with deploying Kubernetes. The Kubernetes deployment process is automated by Jenkins X, which essentially provides a level of abstraction on top of another abstraction.

Dechery conceded there is some level of inherent competition with cloud service providers that provide their own DevOps tools. However, most of those DevOps platforms are not up to the task of building and deploying applications at scale, he said. In addition, platforms such as Jenkins and Jenkins X make it feasible to manage application development projects at scale without having to worry about becoming locked into a single cloud service provider, he added.

Competition across the CI/CD platform space remains fierce. CloudBees has long benefited from a large open source Jenkins community that often leads to organizations implementing an enterprise edition of Jenkins supported by CloudBees. However, as organizations embrace microservices-based applications based on containers, many of them are revisiting their platform options. That doesn’t necessarily mean they will rip and replace existing investments in Jenkins platforms; however, given the rate and scale at which modern applications are being built and delivered today, many organizations may be moving toward more prescriptive approaches to bring some order to the chaos.

— Mike Vizard

April 9, 2020
Sysdig Extends Cloud Monitoring Alliance With IBM

Sysdig and IBM announced they have extended their alliance to make Sysdig monitoring tools more broadly available across IBM public cloud services.

IBM first adopted the Sysdig platform to enable DevOps teams to monitor workloads running on a subset of the IBM Cloud in June 2018. Now the company will extend those managed instances of the Sysdig monitoring platform running on its own public cloud to include additional cloud services such as IBM Watson, Event Streams, Cloud Databases, Cloud Object Storage and Cloud Foundry.

Janet Matsuda, chief marketing officer for Sysdig, said monitoring capabilities as especially critical as the number of microservices-based applications running on public clouds continues to increase. IBM also makes use of the open source Prometheus monitoring platform to monitor many of those applications. Sysdig last month announced compatibility with Prometheus as a data source.

In the wake of the COVID-19 pandemic, it’s probable that more monolithic applications will also be moving into the cloud as part of organizations’ business continuity strategies. Applications that run in the cloud are easier to manage remotely. Regardless of whether applications are monolithic or based on microservices, it’s clear IT teams will be “flying blind” unless they have access to monitoring tools, Matsuda noted.

Over time, many of the monolithic applications being moved into the cloud will be transformed into a more flexible set of microservices that are easier to update. As that transition occurs, the need to observe the myriad microservices running on a public cloud becomes an even bigger challenge for IT teams.

Of course, some IT teams will prefer to employ their own monitoring tools versus relying on a managed service, especially if they are trying to centralize the management of IT across multiple public clouds and on-premises IT environments. However, for now, at least, the bulk of IT teams are still employing various public clouds in isolation from one another.

Longer-term, the relationship between Prometheus and commercial monitoring platforms is still being defined. Many application developers are relying on Prometheus to observe applications during the development process. Many IT teams, however, are already making extensive use of commercial monitoring platforms to identify and correlate issues in production environments. Sysdig is betting most of those organizations will continue to rely on those tools because they are easier to set up and navigate. In addition, each instance of a Kubernetes cluster currently requires its own instance of Prometheus.

On the plus side, the amount of time and effort being applied to instrumentation and observability as part of any set of best DevOps practices continues to increase sharply. Furthermore, the need to combine security and operational IT metrics and analytics to advance DevSecOps adoption is also going to push IT organizations toward more robust monitoring platforms. Arguably, the real challenge is no longer finding a way to instrument applications as much as it will be turning all the data being collected into actionable intelligence that can be relied on to automate the management of IT at an unprecedented scale.

— Mike Vizard

April 9, 2020
Seven Effective Tips to Get the Most Out of your DevOps
It seems that every firm is trying to include DevOps in their software delivery cycle these days. This is understandable. According to the 2019 Accelerate State of DevOps Report, companies using DevOps are more likely to achieve elite performance in software development and delivery.

Companies such as Google and Amazon can be deploying thousands of updates a day. These rapid updates improve company performance and result in the provision of better software solutions for the end-user.

In this article, we will look at seven effective tips to get the most out of your DevOps so you can maximize success. Before we look at some of these tips, let’s briefly define DevOps.

What is DevOps?

DevOps is a term for a group of management practices that aim to quicken the deployment of changes to a system while ensuring high quality delivery. It incorporates management theories such as agile infrastructure and agile development. One of the most influential books on the topic, which resonated with a lot of influential business leaders in Silicon Valley, is “The Lean Startup” by Eric Ries.

At its heart, DevOps boils down to the idea that you should be able to implement changes quickly, so you can release a superior product to your customers faster. This ability to bring a superior product to market fast, gives companies that can achieve this edge an advantage over their competitors.

Review Your Organizational Structure

Collaboration is the bond that allows software companies to deploy and execute changes fast. Companies that are experts at DevOps classically reduce the obstacles to collaboration.

In traditional IT organizations, departments are siloed. They interact with each other only when necessary. Hence, they have limited knowledge of each other’s work. This model presents a linear process of developing, testing and deployment.

To reduce these silos, you need to first analyze your organizational structure, and identify obstacles to collaboration. This starts by ensuring management is on board with your vision. You need to:
- Review the job description of managers and create KPI that support collaboration.
- Create remuneration packages that foster closer collaboration between departments.
Addressing structural issues that impede collaboration between departments will help. You also need to put in place a system of communication between departments.

Fortunately, there are useful tools to smoothen continuous collaboration between different lines of business. Channels of communications should not be limited to sending emails or conference calls. Remember, DevOps requires continuous and fast collaborations to ensure fast deployment.

Using unified communications (UC) is an effective way to foster collaboration in a company. Unified communications integrates phone calls, email, chat, document sharing, conferencing and other platforms necessary to exchange information within the organization. Importantly, you can also access much of this information in one place.

Reduce Operational Hurdles for Deployment

The way an update is deployed will differ by company. There is usually a system in place to discuss targets and a series of checks in place before deployment. For example, department heads will come up with an idea. They will be developed, then reviewed by quality assurance before operations deploy it.

This can be a cumbersome and time-consuming process, which slows down the speed of development. The problem for many companies is that changes, both large and small, need to go through the same process of quality assurance before deployment.

Source: Tech Beacon.

While it makes sense to have this process in place for major updates, it should be possible to push smaller updates faster. Two things need to happen to achieve this:
- Empower staff to make decisions independently while giving them the opportunity to learn from mistakes without risk.
- Reduce the administrative hurdles to deployment by creating a ranking system for reviewing updates. This will allow developers to push small updates independently, or with minimal oversight.
Empowering staff to push changes enables you to speed up DevOps.

Plan in Small Batches

Planning in small batches is important in promoting DevOps in an organization. With small batch testing, the cycles of testing hypotheses, acquiring feedback and going at it again can be done within a very minimal time frame. It is fast and efficient—simple.

This feedback might feel obvious. Perhaps the better question to consider when planning in small batches is: How small is small? Let the INVEST concept in agile development help you out.
- Independent: Planned small batches should be independent of other parts.
- Negotiable: Every batch should be iterable and negotiable upon receipt of feedback from deployment.
- Valuable: Each one should add value to the project and the end-users.
- Estimable: Batches should contain estimable information for scope determination.
- Small: Small should be small enough to be processed within a few hours up to a few days.
- Testable: A planned batch should be testable and can be monitored continuously.
Results of deployment, testing and monitoring of each batch should then be deployed at least once a day. Also, in planning small batches, different departments should be kept in the loop. This will greatly benefit DevOps efforts in the organization.

Create Space for Collaboration

Even without DevOps, fostering collaboration between departments is imperative. You can formalize collaboration through regular meetings. However, departments are usually situated in separate office areas, floors or even different buildings. Think about having to walk to a conference room on a different side of the facility just for a meeting.

This kind of setup is an example of a bottleneck for collaboration in an enterprise. And with collaboration being the heart of DevOps, creating a company culture and office space conducive to teamwork is of utmost importance.

SpaceX is an example of a company that promotes collaboration throughout the organization through company culture and physical space management. Offices are open, and each person can see what everyone else is working on. This promotes motivation for employees to work passionately. Also, everyone has access to camera feeds from different parts of the factory, which inspires curiosity about what others are doing. Because of this culture, employees become dedicated and excited to accomplish results.

Take Advantage of Microservices

In processing complex IT systems, it is more beneficial to break bulks to smaller, more digestible pieces. This is where microservices come in.

Microservices or microservice architecture is an architectural style wherein a complex system is broken down into smaller services. Rather than treating a system as a whole, it is perceived as a collection of manageable pieces.

Teams simultaneously working on parts of a system as a whole makes it more prone to breakdown. Utilizing microservices makes monitoring, maintenance and testing easier. They are also loosely connected to each other which means fixing wouldn’t much affect the other parts. Moreover, each microservice is releasable independently.

As an example, Wix started out with a monolith which was useful at first when they were only handling 1 million sites. However, interdependencies and poor quality coding resulted in downtime which is ultimately bad for business. Now that they shifted to using microservices architecture, they quickly scaled up reaching 70 million sites.

Maintain Continuous Monitoring

DevOps promotes fast and continuous integration and deployment. A fast-paced environment is more susceptible to problems. Something at any point can fail within the software development life cycle. Continuous monitoring helps you identify mistakes fast. It ensures the optimal performance, reliability and health of the software.

Setting monitoring targets, like development milestones, can improve this process. A development milestone is an overarching category that can give an insight into your team’s actual performance. Monitoring tells you the performance of your DevOps implementation.

A method to consider is synthetic monitoring wherein your application undergoes simulated customer interaction. This way, you can monitor the exact action and performance of your software before they get released to actual users.

Practice Change Management

DevOps employs continuous integration, continuous deployment and continuous monitoring. It is a cycle of fast-paced changes. Change management is essential to keep the system run like clockwork.

It might be easier said than done because changes have effects on various stakeholders. This includes your customers as the end-users, security, regulatory compliance and company policies. With this, changes within the development, testing, deployment and monitoring should be cohesively managed.

Change management is intrinsically reactive. It usually happens because of feedback received after deployment. But with DevOps, change management should be proactive. Instead of managing large-scale changes, processes are broken down into smaller parts with clearly defined scopes. Furthermore, anticipated changes are scheduled, scaled and communicated across the board. Possible risks and problems are efficiently managed because of this.

Summary

No system is perfect nor exactly the same. The key to a successful DevOps implementation is assessing what works best for your organization. DevOps is not a standardized process. It is not a system that will work for every company. Rather, DevOps is a theory of management.

Improving DevOps at your firm will involve a system of continuous review and improvement. You need to understand what is working, the problems and what you can improve. This can all be done through continuous processes with the help of automation and collaboration. No matter the size of your software development projects, these simple tips and tricks will help you make the most out of your DevOps.

— Sam O’Brien
April 9, 2020
DevOps Chats: Mobile, Monoliths & Microservices, With LightStep

Daniel “Spoons” Spoonhower made a bit of a name for himself while he was at Google, as did his two co-founders of their latest company, LightStep. All three were there at the birth of the microservices wave that has swept through the software world.

They left Google and started LightStep to help all developers build better, more scalable applications.

With its new release, LightStep has pushed the bar higher. In this DevOps Chats podcast, Spoons tells us what they are doing and where he sees things moving.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel for devopsy.kinsta.cloud and Container Journal. You’re listening to another DevOps Chats. I’ve got a great guest to talk with today, I hope you’re going to enjoy it. I’d like to introduce you to Daniel Spoonhower, better known as Spoons. Spoons, welcome to DevOps Chats.

Daniel Spoonhower: Hi, great to be here.

Shimel: So, Spoons, you are CTO and Co-founder of LightStep, and though some in our audience are probably familiar with LightStep, being that this is the first time we’ve had someone from LightStep on our podcast, I’m gonna ask you to kinda do some of the heavy lifting here and kinda—

Spoonhower: Sure.

Shimel: – tell our audience a little bit about LightStep and what you guys do.

Spoonhower: Sure—sure, sure. So, LightStep provides simple observability for deep systems. We think observability is more than just metrics, logs, and traces, it’s really about being able to navigate from effect to cause. So, whether you’re pushing into deployment, you’re on call and you got paged or you’re just trying to improve performance, observability tools like LightStep should be able to give you the insights that you need to understand what’s happening in your services and across your system.

Shimel: Excellent. And just by way of, again, giving the audience the background—Spoons, why don’t you tell them a little bit about your own personal journey? You are a Co-founder and CTO, but there was life before LightStep.

Spoonhower: True, yeah. So, yeah, I’m Co-founder and CTO and LightStep, but we have three—all three of the Co-founders are technical, and so, we all have done technical things and we all have done a lot of non-technical things, too, which has been pretty fun for me just to learn about finance and about commercial real estate—who knows what.

Shimel: Yeah.

Spoonhower: But yeah, I’m an engineer by training. Before this, I was at Google for a while. I worked both on their internal infrastructure team, which was super interesting, as well as on the cloud platform. And I have various other experiences at big and small companies. I was at grad school for a while doing academic stuff, so—yeah, a lot of different things.

Shimel: Excellent. Alright. So, before we—I know you guys have some new product announcements coming up, but you know, LightStep is, as I mentioned, new to our audience here on the podcast, but it’s been around five years, right? And I think you gave everyone kind of the—you know, the brief elevator pitch about it. But it really, you know, in an age where even just since I’m doing devopsy.kinsta.cloud, right, Spoon, we’ve seen APM turn into AIOps and companies go public in this space and everything, several. But yet, you know, the need to kinda monitor, manage, see what’s happening is still here and I don’t wanna say it’s getting easier or—you know?

Spoonhower: [Laughter]

Shimel: Because I think it’s just, you know, natural. Things get more complex as we continue to build and so forth, and I guess that makes the monitoring easier, but when does it get simpler?

Spoonhower: Well, yeah, so I think the situation has gotten a lot more complex. That might be because of things like microservices or serverless or things like that. I actually think a lot of complexity comes from the fact that we no longer run our whole applications. Like, we use DynamoDB, we use third party fraud detection service, right? There’s a lot of pieces of our software that are not even ours any more, so that adds a lot to the complexity.

Shimel: Yeah.

Spoonhower: I think the simplicity has to come from focusing more on the use cases. Like, what are you as a developer actually trying to get done? And then, I mean—I think this is where people kind of get into things like AIOps is, like, using software to sort of harness the data that we have to help you in that task. I think that can be a real-really nice as a developer, right, to not have to understand all of the depths of what’s going on underneath the hood.

Shimel: Sure. I mean, I just find it somewhat ironic that, you know, we’re gonna break down silos, we’re gonna break up this monolith and go to microservices so that we can deal with smaller, more easily digestible threads, and then we’re gonna orchestrate all of this with a great tool like Kubernetes. And then I look at it, and I’m not the developer you are—I’m not claiming to be, or the technical person—but damn, it gets…it’s just the nature of the universe, at some level.

But anyway, you guys are well aware of this. It’s acute. This is the world you play in. You’ve got some new product announcements. Let’s talk about ‘em.

Spoonhower: Yeah. That’s right, yeah. So, I mean, the history of LightStep a little bit is that we started as a tracing tool, collecting data sort of—exactly to address the situation you’re talking about. You’ve broken your application into some pieces and you want to be able to understand the big picture, right, and put them back together.

And what we’ve done actually is to continue to integrate additional data sources into that, so that we can provide sort of more user-centric things. So, what we’re rolling out right now is a couple different pieces. One is error analysis, so being able to understand, you know, you have a spike in errors in your service, harnessing that data, whether it’s traces or logs or metrics, to understand what the cause of those errors are. We have a detailed rollout analysis, so even if you’re in the middle of a rollout, so you’re saying you’re gonna canary or blue-green or something like that and you wanna understand what’s happening, we’ll do that analysis for you and do a side by side to tell you what’s different about the new release.

And one thing that’s pretty exciting is that part of this is integrating metrics into the platform. Metrics are a tool that everyone has been using forever and ever and ever, but you know, there’s a lot of metrics out there, and part of what we think is important is that we’re able to focus on the right metrics, the metrics that are actually able to explain what’s happening right now.

Shimel: Absolutely. So, this new release, April 2nd, is the key day?

Spoonhower: Yeah.

Shimel: So, people listening to this can go check it out right now at LightStep.com.

Spoonhower: That’s right. We’ve got a free developer tier that you can try. We also have a really cool sandbox that’s sort of, it’s a sort of interactive playground where you can check out features and you can basically walk through one of these scenarios. So, say you’re doing a release, say you’re trying to debug an error or something like that. It’s not—you know, it’s not totally constrained, but will kind of show you along and give you a bit of a guide that you can still explore the rest of the product while you’re there, but really trying to help people kind of put two and two together and understand what’s happening.

Shimel: Yeah, no, I love that, man. Because I gotta tell ya, we’ve been experimenting with something like that for a project we’re doing on devopsy.kinsta.cloud where, you know, we want to have web people do a little bit more hands-on playing with different vendors’ tools and so, we’re trying to give them a sandbox, right, where they can go in and do these things.

Because, you know, we were talking off mic, right? Originally, this was gonna be an announcement around KubeCon which, unfortunately, you know, got pushed. And, you know, not getting into the whole politics and the whole thing around Coronavirus and all this stuff, but certainly, we need—we need more ways, we need more diverse ways of allowing people to see what kind of new products, what new technologies, how can they get it under their nails a little bit and really—

Spoonhower: Yeah.

Shimel: – kind of see if it’s for them?

Spoonhower: Yeah, absolutely. I mean, I think people learn in lots of different ways, right? Some people wanna read, some people wanna watch a video. I personally really like doing this stuff. Like, until I’ve made it, coded it, whatever, I never remember it, so.

Shimel: Absolutely. And you’re not alone. I do think specifically for technology vendors, having those kinda hands on that people can actually go in and we see it even on our webinars, man. If we do a webinar where the vendor’s doing a real live demo that people can follow along, we get insane numbers of people signing onto that, versus someone just talking, you know, and that doesn’t work.

So, let’s talk a little bit about what was driving this, for you guys.

Spoonhower: Yeah. I think, you know, we—so, I should say, when I say “we,” it’s me and one of the other Co-founders. Ben and I spent a while at Google, and Google—it’s a weird place, in a lot of ways, but there are some advantages. Like, there were ways in which being at Google is a little bit like seeing the future, and they weren’t called microservices at the time, but there were a lot of teams that built software that all had to stack together.

And we saw, you know, sort of firsthand the problems that they had in terms of like, okay, I’ve broken this thing into pieces and now how do I understand that bigger picture? We saw a lot of arguments among those teams, like, you know—“Oh, no, it’s your fault,” “No, no, it’s your fault”—and needing some data to actually kinda resolve that.

And so, I think, for us, you know, we saw the rest of the industry starting to adopt these things through different technology, maybe, but the same idea that you can have teams work independently and deploy independently yet still build a single application. And so, the motivation was really to try to help those folks to understand what’s happening and, you know, we see LightStep being used by individuals, but actually more and more by teams. We see it used in operational review so, you know, you’re doing a post mortem, you wanna show people what happened. LightStep is a great tool to help facilitate that conversation.

And for us, this is really about being able to help those folks deliver software more confidently and then, you know, get back to building new features and doing all the fun stuff that they’re doing.

Shimel: Yeah, yeah. I mean, wouldn’t it be great if we just, all we did was the fun stuff all the time? [Laughter] Some of us are lucky enough to do that, me included. But this thing, these are important things that need to get done and, you know, and LightStep is following that up.

I wanted to return to the KubeCon thing if we can, for a second, Spoons. Not KubeCon itself, but rather the Kube community, right? And you know, look, Kubernetes itself comes out of Google, right? I’m not gonna say the Google people invented microservices, but certainly a lot of very foundational work was done there, right?

When you are out and about or you see how this community has grown and the enthusiasm for things like LightStep, right—I mean, how does that, you know, kinda give you a warm fuzzy inside to say, hey, man, this is a whole—there’s this humongous community of people who kinda share our visions or our outlooks, and it’s a lot easier to sell to, and I don’t mean that you’re a salesperson, but it’s a lot easier to sell those solutions, right, than it is—you know, it’s not like pushing rope uphill.

Spoonhower: Yeah, yeah. I mean, I think [Laughter]—yeah, I mean, Kubernetes is a result of a lot of mistakes that were made the first time around. [Laughter]

Shimel: Yeah. [Cross talk]

Spoonhower: So, I think a lot of people would admit that. No, but I think the community is really great. I think the thing that’s pretty exciting to me about it is really thinking about things like infrastructure as code, about, thinking about automation, about—and, you know, these things which we kind of think of historically as, you know, maybe more of a craft actually can be an engineering discipline, and I think that’s a lot of that community. It’s actually really great whenever I’ve been to KubeCon to see the range of folks there from, you know, sort of platform folks all the way up to people that are just building features and shipping code, that they’re also excited about those tools. That’s really, for me, makes a big difference, just to see that it’s not a niche thing so much, right, that it’s really a broad community that’s excited about it.

Shimel: Oh, yeah, no, it’s broad. Me personally, I have 20 years in the security InfoSec space. I get excited when I see all the security people there about it, because I really feel like maybe this time we’ll do better, right? [Laughter]

Spoonhower: [Laughter]

Shimel: And we got out in front of this and where, you know, security is really kinda—it’s not the caboose on the engine, per se, it’s like, people care, and not just the security people care, the community cares.

Spoonhower: Yeah, yeah.

Shimel: And that’s important. So, you know, in today’s world, right, this isn’t this year’s release, this is just the April 2nd sort of new feature. So, what—and one builds on the next, right? So, what’s next here?

Spoonhower: Yeah, so, I think we’re continuing to think about how we can do automated analysis. So, we have a future in the product already called correlations which, essentially, you know, you pick out some effect you think is important, you know? Errors went up, speed went down, whatever it is, and LightStep will find the things that correlate with that within sort of the set of requests that you’re looking at. So, we have a bunch more features related to that coming out later this year.

So, this is kind of how I—I don’t know. When people say AIOps, I always gotta roll my eyes a little bit, but this is kinda how we think about, you know, bringing artificial intelligence to DevOps, right, is that it’s really through sort of putting the right clues in front of you, right? It’s not about providing 10,000 clues to solve a mystery, it’s about 5, right?

Shimel: Right.

Spoonhower: So, a bunch of stuff around that, and then—I mean, the other place that we’re thinking about is how do we get more proactive, right? How do we get in front of you and help you anticipate when these things are gonna be happening as well?

Shimel: Absolutely. So, I suppose one day you’re gonna grow old and you’ll be on this side when—so, I’m no longer building products or founding companies that are building products, and I hear public lands come up with all these…and I don’t wanna say it’s just some marketing term, but—

Spoonhower:[Laughter] You can definitely say that, that’s fine.

Shimel: You know, I will tell you, the first time I heard AIOps, too, I said, “What?” You know? But, you know, I’ve been in technology long enough where—look, just don’t call me late for dinner, right? I don’t really care any more what you call it. And also on the media side of it versus on your side of it, I just report the news, you know, theoretically, right? We don’t—if you wanna call it, you know, if it quacks like a duck and it walks like a duck, it’s a duck.

But in any event, I do hear you about that. And, you know, you wanna talk about an overhyped term? AI?

Spoonhower: Yeah. I think in the world of—in DevOps, I think it’s actually, there’s some—

Shimel: It’s overhyped, itself.

Spoonhower: Yeah, there’s some [Cross talk] though, I think, because you know, if you’re talking about, like, I don’t know, ad placement or something like that, no one really cares about why, right? Like, you put the ad and someone clicks—nice job, right? Like, good job, robots.

But like, you get paged and something’s like, “It’s that service over there, you should definitely roll it back.” And you’re like, “Yeah, but why?” Like, I’m not just gonna start rolling back things because robots tell me to.

Shimel: Yeah, “I said so, that’s why.”

Spoonhower: Right. [Laughter]

Shimel: [Laughter] But I hear you, man, it’s out there. Well, listen, I told you, the time goes really quick here, and I think we’re about out, man. But Spoons, it was great having you on here. Good luck with this new release. I would say I look forward to seeing you at the next KubeCon. Let’s hope there is a next—

Spoonhower: That’s right. I’ll see you somewhere, and if not, online.

Shimel: Yeah. Otherwise, we’ll have you back here on the podcast, man.

Spoonhower: Cool.

Shimel: Alright? Hey, that was Daniel Spoonhower, Spoons, CTO and Co-founder at LightStep. He was just our guest on DevOps Chats. This is Alan Shimel for Container Journal, devopsy.kinsta.cloud, Security Boulevard. You’ve just listened to another DevOps Chats. Have a great day.

— Alan Shimel

April 2, 2020
Splunk Updates SignalFx APM Platform

Splunk today unfurled its first major update to the SignalFx application performance management (APM) platform since acquiring it last October.

Karthik Rau, general manager for application performance management (APM) at Splunk, said SignalFx Microservices APM combines for the first time the SignalFx platform with Omnition, a software-as-a-service (SaaS) platform for implementing distributed tracing as an alternative to application sampling that Splunk also acquired last year.

In addition, the latest iteration of SignalFx adds a Kubernetes Navigator tool to a SignalFx Infrastructure Monitoring module to make it easier to manage Kubernetes clusters alongside the microservices-based applications running on that platform. The module surfaces recommendations to expedite triaging and troubleshooting based on machine learning algorithms that are embedded in the platform. Splunk has also enabled workflow integration across Kubernetes Navigator and Splunk Enterprise and Splunk Cloud to provide IT teams with additional insights and context, noted Rau.

With the acquisition of SignalFx, Rau said Splunk is at aiming to advance two major DevOps trends. The first is the rise of open source agent software that makes it increasingly feasible to instrument the entire IT environment. Omnition, prior to its acquisition by Splunk, was a founding member of and contributor to the OpenTelemetry project now being managed under the auspices of the Cloud Native Computing Foundation (CNCF).

The second is the need to eliminate relying on sampling in favor of employing distributed tracing to be able to analyze every event that has occurred within an IT environment.

At a time when IT environments are getting more complex, Rau said being able to resolve IT issues is critical. Modern applications based on microservices can be especially problematic given all the dependencies involved, he noted. In contrast to legacy APM platforms built to monitor monolithic application environments, SignalFx is built from the ground up to address application environments based on microservices, he said Rau, noting core to that effort is the ability to ingest massive amounts of distributed tracing data.

Historically, APM platforms were used sparingly to help manage the most mission-critical applications in the enterprise largely because of concerns about cost. Given the complexity of modern applications, however, it’s become apparent that observability is now a core tenet of any approach to implementing best DevOps practices. The issue many DevOps teams will need to address is determining to what degree the existing tools they have for observing their IT environments sufficiently meet the requirements of new classes of applications. In many cases, that decision may be predicated on the rate at which those organizations are embracing microservices-based applications.

Of course, Splunk is not the only vendor making a case for an APM platform optimized for microservices. Competition between emerging and legacy providers of APM platforms that have added support for containers and Kubernetes clusters is already fierce. The real issue going forward, however, is determining which of the platforms will enable DevOps teams to discover the most relevant issues soonest. After all, when short-handed DevOps teams encounter an issue, every second it takes to remediate that problem counts.

— Mike Vizard

March 31, 2020
DevOps at Scale: Winning Strategy for Modern Enterprises

DevOps is a word that has generated massive interest over the last few years among the software-powered organizations and developers, yet many people don’t fully understand what it actually means. One thing is for sure, as cool as it sounds, DevOps is not some kind of top-secret developer army group, job profile or even a tool. It is a wonderful ideology that any firm can help itself to unite their tech crew and take the company to newer heights.

As different departments grow, communication becomes difficult between the teams, mainly development and operations. Since communication is the key to avoid unproductive siloing, the DevOps movement started as a cultural phenomenon in order to bridge this gap between dev and ops. So firms started embracing DevOps principles to get everyone on the same page and create a sense of shared responsibility, and moving forward, firms believe that was the recipe for success.

Where Does DevOps Come into Play?

Automation is one of the things DevOps is most known for. Automation reduces the amount of work, and smaller batches of work are easier to understand, commit to, test, review and know when they are done. These smaller batch sizes also contain less variance and risk, making them easier to deploy and, if something goes wrong, to troubleshoot and recover from.

With DevOps best practices like CI/CD, it is easy to understand which code has created bugs and make possible corrections wherever necessary.

Just like lean development, through automation and agile practice, firms can get feature development very close to single-piece flow, and this provides value to customers quickly and continuously by delivering features as quickly as possible.

More traditionally, DevOps is referred to as a means to break down the walls of confusion and chaos between the dev and ops teams and smoothen the flow of communication. In the DevOps model, development teams develop new features, and operations teams keep the system more reliable for customers, stable and running smoothly.

Today, we will see some important elements that help firms to embrace DevOps with ease.

Start a Cultural Shift, a DevOps Initiative

This should flow from top to bottom, company management leaders should start the discipline of embracing DevOps. Usually, it is the CIO who should move the needle and make things start from scratch. A DevOps mindset is very crucial at this point to make sure the teams are all prepared for a change in the culture.

Gartner predicted that through 2022, 75% of DevOps initiatives will fail to meet expectations due to issues around organizational learning and change. One of the main reasons why DevOps efforts fail is that most of the organizational leaders don’t understand Agile and DevOps. Leadership makes a huge impact on the organizational culture and its way of doing business, hence engineering leaders need to understand why this change is necessary and start a culture of collaboration, culture of experimentation and learning, and eliminate the blame game.

Train Your People

Training is one essential aspect for team leads and the people involved under them so they understand what DevOps is, the fundamentals, and why it is important for the organization to embrace it. Training enriches knowledge, collaboration and communication processes between the people working in development and operations teams.

It helps them to get together and get their hands on, test the new technology practices and tools introduced. There are many group courses, boot camps and DevOps experts that can help people get trained in DevOps. It is the firm’s responsibility to set proper expectations and choose the right candidates to train their people.

Build a DevOps Plan with a Strategy

All those engineering best practices that enhance automation, team collaboration, seamless integration and testing that facilitate new ways of software development with ease are key to a DevOps strategy. Firms have to set a common goal, track changes and align teams in a shared environment making them aware of each other’s responsibilities and duties. Implementing Infrastructure as Code (IaC), test automation, integration, deployment and release processes should be a part of it.

Set Policies and Processes

The policy is an integral part of any software powered organization. With security being the priority, this has become a supreme topic in the DevOps world. For every company that has adopted DevOps, the policy is critical. As we all know, policy-driven development is a fundamental concept that fits really well into the DevOps model. This model ensures that information security, ops, development practices, language standards, SRE, sysops administration and development, are all aligned with common goals.

Containerize Applications

Containers are well equipped with the IaC approach and are used in DevOps to instantly deploy applications across various environments. Docker provides the most popular container technology toolset. Docker image management technologies, such as Amazon ECR, have made it easy for developers to perform IT operations, collaborate with each other, share software and enhance overall software delivery productivity.

Containerizing legacy applications will reduce the burden of handling the ever-growing overhead costs and it also increases developer productivity. Container deployment can be an effective solution as containers typically start in seconds. The container image holds all the dependencies, meaning there is no need to add environment-specific configurations. The same image is now portable across multiple systems and environments. The main idea is to make applications able to run anywhere, on any machine and at any given time.

Make Use of Microservices Architecture

Decouple the legacy and monolithic application that involves thousands of lines of code into numerous small elements called microservices. With the idea of microservices, a company continues to innovate and stay agile as the products or the platform gets larger. With this approach, engineering teams focus on developing business capabilities and important features autonomously.

Instead of having to orchestrate a large release after writing hundreds of lines of code, waiting for the perfect time to offer new features, a new business functionality can be added by just adding a new service. Eventually, firms end up creating microservices that can be easily and independently deployed, scaled and managed without having to worry about other parts of the application.

Determine the Toolchain

When companies initially start embracing DevOps they feel proud, but they find it hard once they really start working toward it practically. The simple logic for this is: DevOps is fragmented.

For many years, firms have tried to embrace DevOps and have found themselves making various mistakes by their custom scripts and logic. From source control to CI, to artifacts management to CD, as soon as one task is completed, the next step should proceed without any lag, and that is how the firms achieve their DevOps automation. But in practice, this doesn’t happen.

There are many handovers that take place manually—that is not called DevOps. Custom scripts and practices might work temporarily for a startup but when the company grows, taking different tools and writing code to make them talk to each other becomes a complex task. For this reason, recently, JFrog has launched a unified DevOps platform for companies struggling with doing DevOps at scale.

Companies around the globe are in a race to innovate and release software and valuable features to their customers as early as possible to stay ahead of the competition. You need a platform to deliver software updates fearlessly from code to the edge. It would help if you had an end to end universal DevOps solution, like JFrog platform, to manage your entire DevOps pipeline. A highly scalable enterprise platform unifies the management of all services in a single pane of glass. The JFrog platform is Kubernetes ready to manage your Docker images and Helm repositories for your Kubernetes deployments. It has everything you need to do DevOps, from artifactory repository management to distribution.

Continuously Monitor and Share Feedback

Once we deploy the application in production and make it available for the end-users, the next step is continuous monitoring. This alerts the team if there are any misconfigurations or worse situations of an outage or of any application issues. You can monitor infrastructure health, or if would like to see and analyze logs over weeks and months, you should be able to do so.

This step provides critical feedback, essential for the team to understand and work on the aspects of the application that require additional work and resources. Continuous monitoring enables you to find issues (if any) before any customer finds them. Having no visibility is just like getting your arms tied behind your back, you can’t really see what is going on.

Conclusion

Other than easy collaboration, improved communication, an increase in productivity and effective feedback loops, the one benefit DevOps will bring is delivering software at speed without compromising on quality. DevOps is an ongoing effort and helps people in the organization fail early and learn early from their mistakes, and it builds confidence. DevOps implementation can look too overwhelming at times, but a prepared approach with a well-thought strategy can take your firm from zero to hero. Given that the teams have patience, persistence and ever-learning attitude, it is possible to scale DevOps to new heights.

— Pavan Belagatti

March 31, 2020
Running Kubernetes in Production: Make Sure Your Routing Strategy Works

Managing Kubernetes deployments in production raises some rather complex challenges. The dynamic nature of network communication in containerized environments produces unique operational issues–capable of bewildering even experienced DevOps teams. To mitigate these issues, software-based routing components offer key advantages across a number of areas.

Here are a few particularly important routing strategies to consider within any production-grade Kubernetes environment.

Leverage Tracing and Monitoring

However thoroughly you test applications during development, a fresh round of issues will emerge in production. To help understand (and respond to) these new obstacles, tracing and monitoring tools provide developers with crucial visibility into their runtime Kubernetes environment. Choosing routing technologies that closely integrate with established monitoring and tracing backends will also help make things easier.

All inter-service traffic passes through software routing components. This enables strategic application designs that purposefully collect microservices tracing and monitoring data. For example, tracing tools can identify the source and call flows of microservice invocations (assuming that the application is designed to support traceability). Thus, teams can determine how to fully leverage any available microservice, even those developed by different teams. By designing applications to provide metrics, DevOps teams can also use software routing and monitoring tools to understand production issues. For instance, tracking resource usage metrics for a microservice can reveal if its subcomponents are prepared to handle load at greater scale. That data can simultaneously point out performance limits and aid in troubleshooting new feature implementations.

Secure Communications and Permissions

Security must be a top-of-mind focus in any production Kubernetes deployment. Permissions governing internal network communications need to be tightly controlled to defend against attacks. Sensitive data transmitted within internal and external traffic must be encrypted and secured. Many businesses require data encryption not just as a best practice, but also as a matter of regulatory compliance. Unfortunately, these safeguards are absent in many Kubernetes environments.

Routing technologies make it possible to enforce security policies using network segmentation. For example, only client services with justified business requirements should have access to microservices that handle sensitive data. Routing tools can also provide encryption. Service meshes can secure internal east-west traffic with secure TLS encryption. Edge routers can utilize provided certificates to encrypt all external north-south traffic. In order to fully automate the lifecycle management of trusted certificates, DevOps teams can also pair up routing technologies with services such as Let’s Encrypt. This automation makes it possible to continuously encrypt and secure the transport of sensitive data, with no interventions from human workers required.

Absorb Unexpected Load Spikes

Sudden popularity, DDoS attacks and other unexpected events can trigger surprise load spikes. As a technique, rate limiting enables operators to control the request rates to front-end services. This equips applications to absorb surprise load spikes and avoid failures. In this way, leveraging a routing tool to implement rate limiting techniques effectively limits downtime due to load events.

Resolve Communication Issues

Microservices can become unreachable due to errors by a container, host, network partition or short-term microservice interruption. Therefore, implementing mitigation strategies to keep these communication failures from affecting users is absolutely crucial.

For example, the load balancer can respond to instance failures by directing requests to viable instances (and resuming normal traffic when the instance is available). During microservice interruptions, it’s critical to halt repeated retry requests to conserve resources and avoid cascading failures. Teams should use client services to employ circuit breaking to stop requests, send errors and fallback to alternative procedures.

While it’s possible to implement these mitigation techniques using network-layer logic within each client, that approach is highly challenging and error-prone. Teams are better off utilizing routing technologies to control their applications’ mitigation responses.

Achieve High Availability

Compared to traditional hardware failover solutions, today’s software routing technologies offer a far more effective and cost-efficient means of introducing high availability to Kubernetes environments.

Software routing technology enables DevOps teams to leverage architecture via a separate, horizontally-scalable data plane and a fault-tolerant control plane. The data plane makes it possible to add all the instances necessary to achieve the requisite capacity and resilience. At the same time, the control plane effectively tolerates failures to preserve uptime and safeguard seamless experiences for an application’s user base. A smart routing strategy thus ensures that production Kubernetes deployments are highly available and incredibly resilient.

Deploy Across Multi-Cloud and Other Heterogeneous Environments

DevOps teams may leverage Kubernetes across multiple cloud environments, on-prem environments and even alongside other container orchestration solutions. A routing strategy should meet the portability required to effectively support deployments across these different environments and solutions. By doing so, developers can deploy a common routing layer model across all deployments. This reduces key challenges by enabling a concentrated focus on a single and familiar solution.

Selecting an appropriately advantageous software routing technology can transform the experience of deploying Kubernetes into production. Routing tools provide capabilities that can simplify or even fully eliminate many common challenges (and some uncommon ones). In this way, DevOps teams can take advantage of everything Kubernetes has to offer that much more easily and successfully, while achieving more robust and reliable applications.

To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon EU, in Amsterdam. The CNCF has made the decision to postpone the event (originally set for March 30 to April 2, 2020) to instead be held in July or August 2020.

— Manuel Zapf

March 20, 2020