devopsy.kinsta.cloud

Tag: service mesh

Volterra Service Mesh Service Automatically Discovers APIs

Volterra announced today it has updated a service mesh it makes available via a software-as-a-service (SaaS) platform to include the ability to automatically discover all the application programming interfaces (APIs) in an application using machine learning algorithms, then automatically apply all the whitelist policies that apply to those APIs.

Service meshes add a programmable layer of abstraction above a proxy server that makes it easier for IT teams to provision networking and security services on demand. The challenge is service meshes tend to be complex to deploy and between the service mesh itself and the underlying proxy server software also consume a significant amount of resources.

Company CEO Ankur Singla said Volterra addresses that issue by making VoltMesh available as a service that DevOps teams can invoke remotely to simplify the provisioning of network services without having to deploy and maintain a service mesh on their own. Volterra claims VoltMesh has already been embraced by more than 50 enterprise IT organizations and service providers. VoltMesh can also be globally extended to clusters across multiple cloud providers via an application delivery network (ADN) that the company also manages.

Singla said VoltMesh is shifting control over networking and security services left toward DevOps teams by employing a network fabric delivered as a service that eliminates the need to deploy separate load balancers, API gateways and web application firewalls for each cluster. That network fabric also provides DevOps teams with a zero-trust architecture for networking services that better ensures application security because it is managed by Volterra, added Singla.

In general, service meshes are emerging as a critical linchpin in the convergence of network operations and DevOps processes. Most DevOps teams can provision virtual machines in a matter of minutes. However, outside of a public cloud it can still take days or sometimes weeks to provision networking and security services. Service meshes provide a mechanism for programmatically exposing networking and security services to APIs without requiring networking staff to manually provision each individual appliance, router and switch using command-line interfaces (CLIs) that are unique to each device.

It’s too early to say to what degree IT organizations may decide to rely more on external networking services. However, more organizations are showing a marked preference for devoting more of their limited resources to developing and deploying applications. Everything required to run those applications simply becomes yet another cloud service that can be programmatically invoked.

Naturally, the implications of that transition for network operations teams could be profound. Many organizations have “sunk costs” in enterprise networks measured in multiple millions of dollars. However, at a time when DevOps teams are being challenged to deliver applications faster than ever, tolerance of rigid networking services is declining. Many DevOps teams will simply opt to rely on external networking services in much the same way they opt to employ virtual machines in the cloud versus waiting for internal IT teams to make resources available in a local data center. When it comes to traditional approaches to networking, time and patience are running out.

September 2, 2020
Why Service Meshes Are Security Tools

Are service meshes overhyped, or do they solve a real puzzle for enterprise IT systems? Service meshes are a relatively new technology, and many people have found it challenging to fit them into predefined tooling categories. That’s because service meshes have a wide variety of functionality, from load balancing to securing traffic. But service meshes do more than securing your traffic via mTLS, and they can be very important security tools for your enterprise.

Service meshes help organizations improve their security posture, working to both proactively prevent attacks through encryption and access control as well as to provide visibility into anomalous behavior when security incidents do happen. Service meshes can be a strong addition to organizations’ security tooling and are especially important for securing applications that have both cloud-native and legacy components.

In the past, controlling the perimeter of the network was considered “good enough” when it came to network security. There are two problems with this: First of all, even in legacy systems getting through the firewall was often not that hard and, once in, attackers could access the entire system. Just as importantly, this approach simply does not work for distributed, cloud-native applications that don’t even have a clear perimeter to protect. A service mesh makes it possible to tighten control over traffic inside the virtual network, so even if a malicious actor gets in, its presence is easier to detect and the extent of the damage can be limited.

Service Mesh and Security

Here’s why services meshes should be considered security tools—and how they work to secure modern enterprise applications.

Central Control Over Communications

Modern engineering organizations need to give individual developers the freedom to choose what components they use in applications as well as how to manage their own workflows. At the same time, enterprises need to ensure that there are consistent ways to manage how all of the parts of an application communicate inside the app as well as with external dependencies.

A service mesh provides a uniform interface between services. Because it’s attached as a sidecar acting as a micro-dataplane for every component within the service mesh, it can add encryption and access controls to communication to and from services, even if neither are natively supported by that service.

Just as importantly, the service mesh can be configured and controlled centrally. Individual developers don’t have to set up encryption or configure access controls; security teams can establish organization-wide security policies and enforce them automatically with the service mesh.

Developers get to use whatever components they need and aren’t slowed down by security considerations. Security teams can make sure encryption and access controls are configured appropriately, without depending on developers at all.

Cross-environment Microsegmentation

The ability to control access to different parts of the infrastructure is a key part of any organization’s security posture. But in most modern enterprises, each business unit will have applications running both on-premises and in the cloud—potentially in multiple clouds.

With an agnostic service mesh to bridge environments, organizations can segment networks in a way that still creates a seamless experience for users and doesn’t become too complex for security teams to manage effectively.

Inside each segment, the service mesh can be used to create attribute-based access controls (ABAC), role-based access controls (RBAC) or even next-gen access controls (NGAC). A service mesh allows organizations to tune this access control very granularly, including inside individual network segments and across different deployment environments.

Detailed Telemetry

In addition to providing consistent encryption and access controls, service meshes can also provide the telemetry that organizations need to identify potential security incidents and respond appropriately to anomalies.

Because all traffic moves through the service mesh, the mesh is able to collect and display granular information about network traffic. This includes the ability to track the origin and destination of every request sent through the mesh, which is important both for security as well as for passing compliance audits.

With a service mesh that connects both legacy and cloud-native environments, detailed traffic information is available for the entire system. Security teams can use a single dashboard to see how traffic is moving through the system and to correlate signals to users, IP addresses and content as it moves from one environment to another. Having all the information in one place reduces the risk of miscommunications or miscorrelations as traffic moves between environments, either obscuring a real security risk or raising red flags unnecessarily.

Consistent Cross-environment Security Postures

Most modern enterprises have a hybrid/multicloud IT system that includes legacy monoliths in data centers, cloud-native infrastructure in private clouds as well as workloads running in at least one public cloud. There are legitimate business reasons for all of these infrastructure choices, but organizations need to have a strong, consistent security posture across all of them. Service mesh technology allows organizations to connect all of the services, applications and components in the system, regardless of environment, and ensure encryption, access controls and visibility into traffic flows extend throughout the entire system.

Conclusion

Adding a service mesh to your security toolkit is a way to ensure consistency and compliance across the entire, heterogeneous system, no matter what kind of environments and deployment architectures you have. Ultimately, your security posture is only as strong as your most vulnerable deployment. A service mesh is the best way to ensure that every part of your infrastructure complies with your internal security policies.

August 17, 2020
Revisiting 2020 Cloud Predictions in Light of COVID-19

Back when the technology industry made its cloud predictions for 2020, no one forecasted the impending impact of COVID-19. Across the board, the pandemic has changed the way consumers have digital experiences, and made businesses realize their legacy IT infrastructure may not be up to keeping pace with new demands.

So how does that change some of the cloud predictions put forward at the end of 2019?

Increased Importance of Hybrid Cloud

Hybrid cloud is a critical focus area as IT organizations prepare to work and operate with clouds but many applications continue to run on-premises. While I predicted that hybrid would be a crucial area, I did not expect the actual pace, which has become much higher.

With cloud technologies becoming part of every IT environment from operations to orchestration and beyond, its adoption, including the move to hybrid, will accelerate due to this new normal. More organizations will adopt a hybrid cloud approach sooner than expected, as they’ll have no other choice to keep up with technology’s aggressive evolution. They must run legacy workloads or local cloud on-premises while also deploying on public clouds and manage workloads there; this is from both a VM and Kubernetes perspective. Red Hat and VMware are going head-to-head here.

As COVID-19 severely impacts IT teams’ time and budget, those that provide solutions that are easier to run and integrate will win this space. Simplicity, known skill sets and familiar products with shorter time to integrate will be critical.

Containers Will Still Become the De Facto Software Packaging Model

Container platforms have become an essential factor in the hybrid cloud landscape, accelerating multi-cloud adoption in enterprises. Gartner predicts that by 2023, 70% of organizations will be using at least three containerized applications in production. Even with the prioritization of other tasks due to COVID-19 disruption, container adoption is continuing at full speed, along with the wider implementation of Kubernetes.

COVID-19 should not impact the adoption of containers for those already on a Kubernetes platform. Anyone who has started with Kubernetes uses containers already, and organizations understand the value of Docker-based DevOps, local PC development and CI/CD pipelines based on containers.

2020 No Longer the Year of Serverless Computing

I expected a move toward maturing best practices, security solutions and tooling around serverless computing as more IT organizations looked to implement the technology. I saw AWS Outposts as the likely chief disruptor here, as it blurs the lines between on-cloud and on-premises workloads and services, with Google Anthos and Microsoft Azure as its main competitors.

However, we can now assume that COVID-19 will have impacted the adoption of new technologies. This is because many organizations are unable to deal with new technology due to the other tasks that have taken precedence for now. I also expect organizations that were experimenting with the likes of AWS Lambda or kNative may take a step back for at least three to six months.

Service Mesh Not Yet Standard for Cloud-Native Apps, Microservices

I expected the industry to start uniting behind a single strategy to service mesh in 2020. But as of now, the list of open source service mesh options continues to grow. This makes it one of the most interesting domains today, full of emotions, fights and changes, unaffected by COVID-19.

As a standard continues to elude the industry, things can become highly problematic. This is because once you adopt service mesh, it becomes a critical path in your deployment and application dependency.

A few weeks ago, I spoke with Dell’s CTO, John Roese, who said he firmly believes the industry will eventually converge. Although IBM, VMware, Red Hat, Pivotal and Google commit to Istio as their service mesh, the industry is still waiting patiently for this convergence to happen.

While all of this infighting is happening, a new body, the Service Mesh Initiative, was set up to ensure none of the hyper-scalers could impose a lock-in on service mesh. This could begin to change things, as IT organizations can define applications that use service mesh without tightly binding to any specific implementation. Watch this space.

While COVID-19’s impact may have thrown a few things off base at the start of 2020, it’s likely a temporary slowdown. As new demands require a more flexible IT environment to keep pace, there is no question that things will speed back up. And when it does, IT organizations must be ready to implement the latest innovations or risk being left behind.

July 20, 2020
Kong Donates Kuma Service Mesh to the CNCF

The Cloud Native Computing Foundation (CNCF) announced today it has accepted the open source Kuma service mesh developed by Kong as a sandbox level project.

At the same time, Kong announced an update to the service mesh for monolithic and microservices-based applications that makes it easier to deploy multi-tenant instances of Kuma across multiple types of networking environments.

A service mesh provides a layer of abstraction across networking environments that simplifies the deployment of distributed applications. Rather than having to manually configure each application service for a specific network, the service mesh automatically routes application traffic across multiple network underlays.

Kuma is based on Envoy, an open source proxy server developed under the auspices of the CNCF. Kuma will be the second service mesh project that CNCF has accepted after Linkerd. However, Linkerd is not based on Envoy, so the CNCF is adding another service mesh project.

Kong CTO Marco Palladino said Envoy provides an opportunity to create a lighter-weight service mesh that is easier to deploy across a distributed computing environment.

Arguably, the best-known instance of a service mesh is Istio, which was developed by Google, IBM and Lyft for Kubernetes clusters. Istio, however, is complex to deploy and manage, and it hasn’t come under the auspices of any open source consortium.

Palladino said given the popularity of Envoy, it only makes sense to add a service mesh that is both lighter-weight, scales better and is more extensible. For example, the latest release of Kuma adds support for global/remote control plane replication across hundreds of thousands of data plane proxies, he said.

Also added was an ingress data plane mode that automates cross-platform and cross-cluster service mesh communication and a native universal DNS service discovery application programming interface (API) that makes it appear multiple services are all sharing the same cluster.

As a sandbox-level project managed by the CNCF, Kong is now inviting other organizations to contribute to the development of the Kuma service. It remains to be seen which service meshes will eventually gain broad support. In addition to Kuma, Istio and Linkerd, the open source Consul service mesh from HashiCorp is vying for support. There are other proxy servers as well, such as NGINX, on which service meshes can be constructed.

Very few IT organizations have deployed any type of service mesh in a production environment. However, as the number of microservices being deployed steadily increases, IT organizations need an easier way to enable applications to invoke network resources. Kuma provides a service mesh to address that issue that can be employed by both emerging microservices-based applications and legacy monolithic applications.

Kuma also makes it possible to more easily secure traffic, establish service connectivity permissions and capture metrics using a combination of routing rules that can be set using APIs, says Palladino. It also comes with out-of-the-box policies for the most common service mesh use cases.

Service meshes should also play a major role in the eventual convergence of network operations (NetOps) and best DevOps practices. Network specialists still will be needed to deploy the physical network underlay. However, network services themselves are becoming a virtual abstraction that developers can invoke within the parameters of policies defined by a central IT organization.

The challenge now is advancing service mesh platforms to the point where the average enterprise IT team is capable of deploying and managing them.

June 30, 2020
HashiCorp Extends Consul Service Mesh Reach

HashiCorp today made available an update to its Consul service mesh that makes it easier to integrate legacy and modern applications.

Service meshes have emerged as a framework for documenting and controlling how application services interact with one another. Most of the adoption of service meshes thus far has involved applications built using microservices. With potentially hundreds or even thousands of microservices to manage, a service mesh framework becomes essential.

HashiCorp Consul 1.8 extends the reach of the Consul service mesh by making available additional gateway and compliance features that make it easier to integrate any service into any mesh, in addition to adding support for audit Logging and single sign-on (SSO) capabilities.

Amith Nair, vice president of product marketing for HashiCorp, said organizations that adopt Consul can apply a service mesh to both microservices and monolithic applications. That approach also eliminates the need to deploy a service mesh such as Istio, which only works when deployed in conjunction with a Kubernetes cluster.

In general, Nair said Consul enables IT organizations to gain the benefits of a service mesh without being required to retire existing application services or manage them in isolation from modern cloud-native applications.

Longer-term, Nair said HashiCorp expects an ecosystem to develop around Consul as technology partners extend the core capability of a service mesh to add, for example, application firewall services.

It’s too early to say to what degree IT organizations will embrace service meshes as a technology. However, as IT environments become more complex many enterprise IT organizations are shifting toward managing services rather than individual applications. That approach enables IT organizations to align their IT strategy more easily with specific business outcomes.

At a time when many organizations are also trying to accelerate a transition to digital business processes in the wake of the COVID-19 pandemic, most of those digital business processes are typically a collection of loosely coupled application services that could be managed via a service mesh.

Nair said while it’s still early in terms of adoption, most enterprise IT organizations are now at least aware of what a service mesh does and why they might need to deploy one. The challenge, of course, will be getting IT organizations to prioritize the deployment of a service mesh when many IT budgets have become suddenly constrained. It’s also not clear who inside of those IT organizations will fund service mesh projects, which benefit a variety of application projects—application owners tend not to directly fund centralized IT management services, which leaves it up to IT leaders to fund. The challenge is, most IT budget dollars are already allocated.

In the meantime, developers will continue to embrace everything from Kubernetes to serverless computing frameworks. However, the rate at which new applications are deployed generally far exceeds the rate at which applications are retired. As such, IT organizations should expect to find themselves managing a wide array of different types of application services for many years to come.

May 14, 2020
Buried in Code

May 4, 2020
How Integration Can Keep Up with Digital Demands

Integration holds the key to accelerating innovation, but in many organizations, business systems and application integrations haven’t kept up with the demands of digital. Data still exists in a siloed blend of on-premises systems and unconnected cloud applications, and IoT has added another layer of complexity into the mix.

Understanding the three trends below, and how to leverage them, will help organizations continue to drive innovation for years to come.

The Rise of the Integration of Things

It’s no secret that the adoption of IoT is increasing, generating massive amounts of data from devices and sensors. As the number of devices increases in response to the explosive growth of IoT, the amount of data increases exponentially. This explosion of devices–and its associated data–is driving the need to leverage that data for the benefit of the business, such as improved customer experience, cost and downtime reductions or efficiency and productivity gains.

Integration is the key piece that will enable businesses to get control of this data and put it to work. Without the right integration tools, it’s only possible to leverage IoT at specific levels. Essentially, integration provides the ability to connect the data from IoT devices and enterprise applications, orchestrate workflow and enrich IoT data with contextual information from other systems for better decision-making.

Organizations can even use integration to link IoT platforms together for a comprehensive view of data, analytics and actions–making it easier and quicker to analyze, draw conclusions from and determine how to use the data. On top of this, they can also create complex and sophisticated responses when something goes wrong by leveraging automated integration workflows.

As we continue to connect our devices, the Integration of Things will be as important as the Internet of Things.

Blurred Lines Between Application Development and Integration

For cloud applications to survive and thrive, they require built-in integration with other apps and data sources. Otherwise, users are constantly switching contexts from one tool to another when trying to complete a task, and content is scattered across the organization in multiple applications and departments. Because of this, the lines between application development and integration will blur as apps are compelled to have integration embedded under the covers.

There will be many benefits to this. First, organizations will easily create and deploy integrations directly within their products, fully baked into the user experience. These in-app integrations to third-party sources will unlock additional capabilities for users, empowering them to do more.

Second, building integrations without the right tools and specialized integration know-how requires a lot of work. Embedded integration eases the pain of monitoring API changes and documentations so that maintenance is smoother and cheaper.

Finally, business services can involve complex interactions with cloud apps and data that require ordering, have dependencies or may even need to be reversible on demand. Organizations can handle these sophisticated jobs by leveraging advanced integration orchestration to manage app interaction–meaning that instead of using manual code for complex data mapping, they can create a visual drag-and-drop data flow.

AI Powers Smarter APIs

Businesses have already been leveraging intelligent automation to improve operations, drive innovation and personalize the customer experience. As we head into the new decade, API management will harness the power of AI with innovative ways of protecting and controlling APIs and the applications they serve.

Service mesh, an increasingly popular way of discovering and observing services in distributed networks, will evolve into app mesh, an application-aware model of monitoring, managing and securing your APIs. API policies will be able to reconfigure dynamically based on traffic, security threats and identified patterns. Additional layers of defense will come from bots deployed in an organization’s network to constantly monitor behavior and these bots will use machine learning to improve automated threat responses for APIs.

The integration landscape is changing, but understanding how to harness these trends will ensure organizations are well-equipped to take advantage of evolving technologies for innovation.

— Ann Marie Bond

February 7, 2020
Building a Real-Time App: 13 Open Source Projects You Should Be Tracking Right Now

Open source is the dominant model of software consumption in the modern era. Cutting-edge startups and entrenched incumbents alike find open source software development and community building a significant part of their overall business strategies.

For many open source projects, independent steering committees ensure that projects remain stable and are not beholden to a single company or profit motive. Alternatively, for open core projects where a single company financially supports and contributes the vast majority of open source code, open sourcing makes a project publicly available and accessible for potential new users. Opening a project to public contribution widens the pool of potential users and contributors, therefore ensuring more rapid innovation than commercial software offerings.

Choosing the Right Open Source Projects for Your Real-Time App

There are seemingly limitless open source projects to evaluate. Further complicating matters, each project has its own domain competence and cultural nuances. Considering a single distributed application will have tens or (many) more open source dependencies, development teams must continuously test new open source offerings and hone new skills to use these solutions, while simultaneously architecting their applications.

In order to help sort through the noise, I’ve looked at six categories of open source projects for this article: data storage, message systems, service meshes, REST frameworks and streaming frameworks. For each category, I’ll identify any dominant players as well as some other projects of note.

Here are the top 13 open source projects by category.

Data Storage: Cassandra, Hazelcast

Apache Cassandra, originally developed at Facebook, is one of the most widely used open source projects for real-time applications. Functionally, it’s a distributed NoSQL database management system. But practically, it’s become the linchpin of most at-scale, real-time applications. This is because Cassandra was designed to handle large amounts of real-time data across many servers, and has robust clustering support.

For applications that require extremely low latency or have exceptionally high data rates, Hazelcast may provide a useful alternative. Unlike Cassandra, Hazelcast is an in-memory data grid database, which enables development teams to benefit from the latency advantages of in-memory computing.

Message Systems: Kafka, Pulsar, NATS

Apache Kafka is the dominant open source messaging system used by application development teams today. Originating at LinkedIn, Kafka has grown into the de facto standard for high performance open source messaging systems. For streaming use cases, Kafka users can also turn to Kafka Streams.

Apache Pulsar, developed at Yahoo!, is another alternative messaging system which has been optimized for streaming data sources. Pulsar further differentiates itself with TTL message support and queuing via shared subscription.

For applications where latency is a critical consideration, NATS.io (a CNCF project) is one of the fastest pub-sub messaging systems available.

Service Meshes: Istio, Linkerd

Trends such as microservices, serverless and hybrid cloud deployment have contributed to the increasing architectural complexity of distributed applications. With hundreds or thousands of distributed application services, service meshes provide a mechanism for pulling all the disparate services together into a manageable and cohesive whole.

The most notable open source service mesh offering is Istio. One of the most popular open source service mesh projects, Istio is primarily used for applications built on top of Kubernetes. Another alternative is Linkerd, a flexible service mesh solution for Kubernetes or other frameworks.

REST Frameworks: Node.js, Spring

Node.js is a popular JavaScript framework for building scalable web applications. When comparing web development frameworks, Node.js typically ranks among the top three most (along with frontend frameworks React.js and Angular.JS). While Node.js can support large scale applications, it does not support real-time use cases well at scale.

Spring is another application framework, optimized for distributed microservices-style architectures. Like Node.js, Spring “focuses on the ‘plumbing’ of applications so that teams can focus on application-level business logic, without unnecessary ties to specific deployment environments.”

Streaming Frameworks: swimOS

SwimOS is a software framework for distributed streaming applications. Unlike REST-based frameworks, swimOS utilizes a unique and lightweight Web Agent architecture, optimized for composing and transforming many data streams in real-time. Whereas DevOps oriented projects, such as Spinnaker, seek to provide an abstraction layer to converge distributed cloud services, swimOS provides an abstraction across distributed data streams, so teams can build applications by composing many distributed data streams in a single mesh environment.

In order to ensure real-time consistency of distributed services, swimOS automatically ensures eventual consistency between all Web Agents. Complete with a UI toolkit and it’s own stateful messaging protocol called WARP, swimOS is the fastest way to build stateful streaming applications.

DevOps: Kubernetes, Spinnaker, RancherOS

Kubernetes is one of the most talked about open source projects in the world. Kubernetes describes itself as “an open-source system for automating deployment, scaling and management of containerized applications.”

While it may simply be a platform for container orchestration, rightly or wrongly, Kubernetes has become a stand-in for DevOps on the whole. In spite of its dominance, there are alternatives to Kubernetes, for example there’s RancherOS to manage Docker containers.

Furthermore, as application architectures continue to become more distributed and complex there is a need for platforms which can converge multiple distributed edge and cloud environments. Spinnaker provides an abstraction layer to connect the various environments and provides a simple mechanism for continuous integration/continuous delivery (CI/CD).

Final Thoughts

Your own particular use case should determine the appropriate open source technologies for your team’s real-time application. Whether you’re building an ultra-high performance low latency application or simply trying to tame large volumes of real-time data, knowing your options and choosing the right framework or platform can save you significant time and effort.

The open source software landscape is changing every day. If you have something to add about one of the technologies above or think I skipped over the next OSS breakthrough, I’d love to hear about it. Let me know your thoughts in the comments section below.

— Chris Sachs

January 8, 2020
Service Meshes: Improving Security, Delivery and Availability
Containerized microservices are taking over the software world. These services provide developers a way to quickly create and deploy cloud-native applications. However, containers aren’t perfect. Orchestrating and managing container deployments can be a serious challenge.

To help ease this challenge, service meshes were developed. In this article, you’ll learn about service meshes components and architecture options. You’ll also learn how services meshes can improve your container deployments.

What Is a Service Mesh?

A service mesh is a dedicated communication layer that sits on top of your request/response layer. It works similarly to a Container Networking Interface (CNI), which controls the connection of your services to your network. A service mesh sits on top of your CNI, adding additional functionality, such as service discovery or security. A service mesh is not a replacement for a CNI or a service orchestration platform.

Services meshes are designed for use with containerized microservices. You can use this technology with any container or container orchestration tools. However, the most active projects seem to favor developing service meshes for Kubernetes.

Service Mesh Architectures

When deploying a service mesh, there are three architectures you can choose from.

Library

The library architecture employs a library that is imported in an application’s code and runs from inside the application. Using a library eliminates the need to call out to a remote service, making it more secure.

Libraries make it easier to allocate resources since all work is contained in the microservice running the library. A library architecture works well for in-house applications that are written in one language. Third-party applications are difficult or impossible to add the library to.

Node Agent

A node agent architecture uses a node agent or daemon that serves all containers on a particular node. A node agent architecture is language-agnostic since it doesn’t run from inside your microservice. It can be used with in-house and third-party applications. However, node agents must be coordinated with infrastructure processes, making this architecture more complex to deploy.

Node agents require less memory than sidecars since information can be shared across a node. This architecture employs work resource sharing, with dynamically shared resources, making it easier to scale. The downside of sharing, however, is that it can be abused, with one service hogging all available memory.

Sidecar Proxy

A sidecar proxy architecture uses sidecars that run alongside your containers. The sidecar handles all traffic into and out of the container it is attached to. Sidecars do not require coordination with your infrastructure since one proxy is assigned to each container. This lack of coordination makes sidecars easier to set up than node agents.

Sidecars only serve one pod and are not influenced by other pods. This isolation makes this architecture better for zero-trust deployments as each container is accountable for its own actions. Sidecars can be added to containers at any time, enabling you to easily scale processes.

Use Cases For Service Meshes

Service meshes are an emerging technology, with new use cases being actively developed. The three use cases introduced here are just the ones that are currently most common.

Improving Security

Containers are isolated environments and generally considered to be more secure than traditional applications. However, containers still contain vulnerabilities, such as possible abuse of root access.

Service meshes can help address security concerns by providing:
- Zero-trust security—any communication, either from inside or outside requires verification. Verification prevents compromised containers from interfering with other microservices or your broader system. It restricts a container’s actions and communications to that container alone.
- Communication tracing—enables you to collect communications information and isolate errors or issues. If a container is communicating in an unexpected way or against protocol, you can identify it. Once identified, you can easily replace the container with an uncorrupted image or remedy the issue. Tracing enables you to pinpoint possible attacks, including where attackers came from and what they’re trying to accomplish.
Improving Delivery

Containers already improve on application and service delivery by making it easier to release and patch services. Service meshes expand upon these capabilities by improving application and performance monitoring functions.

Service meshes can also help improve service delivery by enabling:
- A/B testing—provides advanced routing, enabling you to divide traffic between A and B versions. This routing makes it simpler to set up A/B testing. Additionally, tracing features enable you to gather and analyze user traffic and interactions.
- Rapid versioning—new versions can be released with zero downtime and reduced risk. Containers can be started and verified healthy before traffic is gradually shifted between versions. If issues arise, changes can be rolled back without system-wide consequences. Easier corrections enable you to relax delivery requirements with minimal risk.
Improving Availability

Containers can provide improved availability, depending on your hosting configuration and resources. Service meshes can expand upon these abilities by improving load balancing, traffic management and health monitoring functionalities.

Service meshes can also help improve availability by enabling:
- Resilience testing—enables you to test how services respond with fault injections. Service meshes enable you to test your services’ fault tolerance. Increased understanding of how faults affect resilience helps you identify and correct vulnerabilities. Greater service resilience leads to greater availability.
- Deployment and request shadowing—enables you to simulate anticipated traffic flow and see how services respond. Shadowing enables you to test the traffic and workload capacities of your services. With this information, you can determine whether you need to scale resources and connections. Proper scaling ensures that your traffic needs are met and prevents traffic bottlenecking and decreased availability.
Conclusion

As microservices become standard, teams are placing an increased focus on improving container performance and security. The development of service meshes is a result of this increased focus.

Hopefully, this article helped you understand what service meshes are and how this technology can help improve your container deployments. If you’re interested in seeing how a service mesh might help you, check out this tutorial explaining how to build a service mesh.

— Gilad David Maayan
January 7, 2020
Predictions 2020: Infrastructure and Ops Trends to Watch in 2020

Today, modernizing systems is more than simply moving technology to a new location. It requires an IT stack of a new generation of technologies and tools to work.

As we head into the new year, let’s take a look at the top eight trends that will shape how we will develop and deliver software.

Kubernetes

Yes, it’s big and getting bigger. The pace of enterprise adoption of this leading container orchestration solution will only gain momentum in 2020. Look no further than the 2,300% attendance increase from KubeCon 2015 (500) to KubeCon 2019 (12,000). As more companies begin to see the direct financial and operational benefits to the flexibility, scalability, automation, high availability and portability of Kubernetes, the demand for developers and engineering experts in this complex software will grow accordingly. Case in point: A 2019 national job search on LinkedIn turned up 16,744 open positions for Kubernetes-related roles. Given the already large and still developing Kubernetes community, we should also see an increase in the speed and volume of feature releases.

Microservices

It’s predicted that by 2022, 90% of all apps will feature microservices architectures. The growing business imperative for software engineering teams to produce and release software in ever shorter cycles—continuous delivery—has paved the way for a huge surge in microservices, the ideal architecture for CD. As enterprises continue their accelerated move to the cloud in 2020 and beyond, they increasingly prize the flexibility to try out the new technology stacks that microservices provide. All businesses want to optimize resources, minimize downtime, reduce infrastructure costs and avoid technology or vendor lock-in. In 2020, microservices architectures will continue to offer up more and better of all these benefits as the migration from monoliths picks up speed.

Service meshes

The rise of microservices has led to a parallel boom in service meshes. This will only accelerate, given how integral the current class of service meshes—Istio, Linkerd, Consul, Envoy—is to the successful functioning of microservices. As a software designed to enable the thousands of microservices that make up an application to talk to each other, it’s quickly become an essential component with a vendor ecosystem poised for substantial growth. Feature-rich Istio, backed by IBM, Google and Lyft, is the leading Kubernetes service mesh, and that shows no signs of changing in 2020, especially given the relative ease of setting up and running it. If your enterprise has embarked on the journey from monolith to microservices, it will soon be crossing paths with service meshes.

Observability

In the recent past, the sheer complexity of modern distributed systems has outstripped the tools designed to allow teams to see into them. Enter observability—which isn’t monitoring. Like good helicopter parents, software engineers, application developers, SREs and DevOps teams want to know and understand what their systems are doing at all times. LightStep, Datadog and Honeycomb, to name a few, are vendors poised to offer logging, tracing and metrics solutions to the rapidly growing number of enterprise teams building cloud native systems. Keep a close eye out for OpenTelemetry, an open source observability framework currently a member of the CNCF Sandbox.

SRE

One of the great challenges ahead for this still-emerging field is for enterprises of varying sizes and work cultures to find a form of SRE that works. What succeeds at Google may not be the recipe for SRE implementation at smaller tech enterprises or startups. The role of SRE and the expectations that go with it remain fluid. The SRE’s constant imperative to automate will only add to the profile of critical SRE and DevOps tools such as Terraform, Ansible and Jenkins. Ponder Amazon’s Prime Day 2018 losses of up to $99 million for a clear understanding of the business-critical importance of SREs in the years to come. The job market reflects this new reality.

Security

The shift-left movement in the software development lifecycle is on. The days of bolted-on post-production security are rapidly fading. DevSecOps, though still a buzz term, is here to stay, with more practice and use cases added to the theory. There are huge opportunities here for automated application security tools that support the software development workflow.

Then there’s privacy. The GDPR took effect last May and the California Consumer Privacy Act takes effect January 1, 2020. On top of these, there’s HIPAA and the regulatory compliance pressures on businesses in the area of security, which are already enormous—plus the immense challenges of cloud security. A 2019 Symantec survey on cloud security threats reports that 65% of businesses in the cloud still aren’t using multi-factor authentication. The same survey also notes that an astounding 85% of Symantec’s cloud customers aren’t employing security best practices. Look for businesses to tend to security earlier in the process.

Serverless

It’s a boom time in serverless, with Google’s Functions, Microsoft’s Azure Functions and IBM’s OpenWhisk all offering their serverless solutions following the 2014 rollout of AWS Lambda. Look for more businesses to adopt a serverless-first approach as they upgrade legacy systems and see the substantial cost saving and application development benefits. Startups, too, will see the cost-cutting upside and the agility that serverless brings. The changes in application development and architecture in the cloud as a result of serverless are hard to overstate. With the vendor solutions now on offer, developers are freed up to do what they most like to do: run code and add functionality to their application, faster, without worrying about scaling and availability. Like microservices, serverless will see a huge upsurge in usage as the age of the monolith fades.

DevOps

With the demands of cloud computing and far greater enterprise investment in dedicated teams, DevOps in 2020 is poised to make the transition from policies and principles to actual practice. The addition of baked-in security to the DevOps realm—DevSecOps—adds urgency to the automation of building, provisioning and deploying secure software. ML- and AI-driven apps have arrived, and DevOps practices will play a large role in the development workflow. The goal of zero-touch automation looms large, and this adds urgency to the need for clean data, organizational buy-in and more integrated systems. AIOps, though getting plenty of attention, is still young and its benefits to IT operations are still more theoretical than actual–but stay tuned.

As we head into 2020, it will be exciting to watch these trends unfold. DevOps teams can expect the way we develop and deploy applications–in any architecture–to continue to evolve. By keeping a pulse on new developments in Kubernetes, microservices and other new technologies, they’ll be well prepared to bring their businesses into the new decade.

Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

— Kelsie Pallanck

December 24, 2019