devopsy.kinsta.cloud

Tag: service mesh

  • CNCF Adopts Meshery to Advance Service Mesh Management

    CNCF Adopts Meshery to Advance Service Mesh Management

    The Cloud Native Computing Foundation (CNCF) announced this week during the ServiceMeshCon/KubeCon + CloudNativeCon conference that Meshery, a service mesh management plane created by Layer5, has become a sandbox-level project.

    In addition, Layer5 has also donated Service Mesh Performance (SMP), a set of tools for measuring the efficiency of a service mesh, to the CNCF. SMP provides an open source framework to define standardized benchmarking practices, performance test configurations and measurements as part of an effort to create a MeshMark index for rating a service mesh. A set of service mesh performance methodologies will also be published by the IEEE later this month, developed in collaboration with engineers from Layer5, Intel, Red Hat and HashiCorp.

    Layer5 CEO Lee Calcote said the goal is to make it simpler for IT teams to determine which service mesh to employ based on their specific use case requirements.

    Several service mesh platforms are starting to gain traction as a means to both manage application programming interfaces (APIs) and provide a layer of abstraction between lower-level networking and security APIs that makes those services more programmatically accessible to developers.

    Meshery itself is an implementation of SMP and the conformance tool created for the Service Mesh Interface (SMI), a separate CNCF project to promote interoperability between service meshes. Meshery is based on a set of microservices that are designed to make the platform easily extensible.

    That approach makes it possible to manage multiple instances of service meshes that might be deployed on virtual machines as well as Kubernetes clusters using a range of management tools that are part of the Meshery project.

    Meshery supports AWS App Mesh, Citrix Service Mesh, HashiCorp Consul, Istio, Kuma, Linkerd, Network Service Mesh, NGINX Service Mesh, Open Service Mesh and Traefik Mesh. Meshery also provides IT teams with more than 60+ best practices in the form of templates that can be used to deploy a service mesh.

    It’s still early days as far as adoption of service mesh in the enterprise is concerned. Most IT teams still rely on either proxy software or a gateway to manage APIs. However, as the number of APIs that need to be managed steadily increases, it won’t be long before many IT teams start to at least evaluate a service mesh.

    In the longer term, the impact those service meshes are likely to have on the management of IT could be profound. It is becoming apparent that a service mesh also provides a higher level of abstraction for invoking networking and security services. In fact, the service mesh may wind up playing a key role in driving the convergence of network and security operations with DevOps best practices.

    In the meantime, IT teams will need to decide to what degree they may want to standardize on a single service mesh versus letting individual teams implement their own preferred platform that could one day be centrally managed via Mashery. One way or another, the way APIs are managed and invoked will soon fundamentally change forever.

  • F5 Networks Planning Open Source Projects Beyond NGINX

    F5 Networks Planning Open Source Projects Beyond NGINX

    F5 Networks today revealed plans to launch multiple projects in the months ahead that will extend its commitment to open source beyond the NGINX proxy software the company acquired in 2019.

    The announcement was made during an online NGINX Sprint event; two of the projects are extensions of NGINX that will address networking requirements between microservices-based applications in addition to the management of fleets of NGINX instances. The third project is a platform-agnostic open source developer tool for building modern applications that does not necessarily require NGINX proxy software.

    At the same time, F5 Networks also unveiled an open source NGINX Modern Apps Reference Architecture that gives IT teams access to a complete, fully operational microservices-based application that can be deployed in minutes on a Kubernetes cluster. Based on a modular approach made up of open source components that come pre-wired and pre-integrated, F5 Networks is committing to extending this framework in collaboration with multiple third-party vendors and organizations.

    F5

    Rob Whiteley, general manager for the NGINX product group at F5 Networks, said the company is also committing to modernizing its NGINX proxy software to leapfrog rival open source Envoy proxy software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). NGINX is still more widely employed than Envoy largely because it is lighter-weight and easier to deploy, but Whiteley conceded that Envoy has more advanced capabilities.

    Envoy, of course, is at the core of the Istio service mesh. F5 Networks supports both Istio as well as a service mesh it has developed on top of NGINX. Depending on the number of application programming interfaces (APIs) that an organization needs to support, an IT team might make use of proxy software, ingress controller or an API gateway for a service mesh to manage them.

    Finally, F5 Networks said it will participate in the Kubernetes ingress project and that it is joining the gateway API community as its implements its own NGINX-based gateway controller to ensure its proxy software and Kubernetes remain tightly aligned in the future.

    In general, Whiteley said F5 Networks also is making a commitment to be clearer about where the line between the open source and commercial editions of its offerings is drawn. As a rule, the open source editions are designed for developers and small teams while the commercial version is designed to scale within enterprise IT environments. The overall goal is to promote innovation without enabling cloud service providers to reap all the revenue benefits of F5’s research and development by creating a service based on that open source software, said Whiteley.

    As part of that effort, F5 Networks is expanding the number of open source projects it supports to make it easier for developers to contribute code beyond the core NGNIX proxy software, said Whiteley.

    It’s not clear to what degree F5 Networks will be able to rally the open source community to advance additional projects beyond NGINX. The company is promising to provide additional details at an unspecified future date. However, Whiteley said there is still plenty of room for innovations not only in emerging technologies such as service meshes but also proxy software that is already widely employed within many enterprise IT organizations. Especially since most of them are embracing microservices-based applications that will ultimately change every aspect of IT.

  • Kong Integrates Service Mesh with OPA

    Kong Integrates Service Mesh with OPA

    Kong, Inc. today announced an update to Kong Mesh, built on top of open source Kuma service mesh, that adds support for Open Policy Agent (OPA) software that enables DevOps teams to manage compliance as code.

    Kuma and OPA are both being developed under the auspices of the Cloud Native Computing Foundation (CNCF). Kuma, unlike other service mesh offerings, provides connectivity across both microservices-based applications running on Kubernetes platform and monolithic applications deployed on virtual machines.

    In addition to adding support for OPA, the 1.2 release of Kong Mesh adds authentication mechanisms between the global and remote control planes operating across multiple zones. That functionality extends the Kuma Discovery Service (KDS) to support multiple authentication mechanisms.

    Finally, Kong has added support for the federal information processing standard (FIPS).

    Like the Istio service mesh, advanced by Google and IBM for Kubernetes environments, Kuma is based on open source Envoy proxy software. In contrast, however, Kuma is both lighter-weight and designed to span both cloud-native and legacy application environments.

    Marco Palladino, CTO at Kong, said OPA support will be a significant advance for both classes of workloads as organizations start to employ Kuma within the context of zero-trust computing environments. As DevSecOps processes are extended to include managing compliance as code, OPA will provide a programmable mechanism for ensuring that policies are not only properly implemented, but can also be easily audited, Palladino said.

    In general, an effort led by Kong, VMware and others to elevate the service mesh conversations to more broadly address application connectivity is underway. A service mesh, at its core, provides the means for integrating hundreds of application programming interfaces (APIs) at scale. It also provides a level of abstraction above the network layer that makes it easier to connect applications across a heterogeneous networking environment.

    Kong is making a case for a lighter-weight approach that spans multiple platforms and is highly extensible. As such, third-party vendors and IT teams can add extensions to Kuma as they see fit.

    Ultimately, Palladino said, the time has come to take cloud computing to the next level. If all organizations wind up doing is lifting and shifting monolithic applications to public clouds, an opportunity to advance the state of IT will have been lost.

    Of course, it’s still early days as far as adoption of service meshes are concerned. Most organizations today are relying on API gateways, proxy software or ingress controllers to manage APIs. It’s not clear to what degree a service mesh may remove the need for some of that existing application connectivity middleware.

    Regardless of which approach is ultimately favored, it’s apparent that, as microservices-based applications become more widely deployed, a different approach to application connectivity will be required. Monolithic applications, however, are not going away. In some cases, a monolithic application might be carved up into a smaller set of microservices, but it’s unlikely that every existing monolithic application will lend itself to that architecture any time soon.

  • HashiCorp Expands Managed Services Offerings

    HashiCorp Expands Managed Services Offerings

    HashiCorp today announced the general availability of its Consul service mesh as a managed service on the HashiCorp Cloud Platform (HCP) along with a beta release of a managed instance of HCP Vault, a secrets management platform, on HCP.

    HCP is currently hosted on the Amazon Web Services (AWS) platform, on which the company is making available its complete portfolio as a managed service. In the longer term, HashiCorp plans to make its managed services available on all the major cloud platforms.

    Chris Kent, director of product marketing for HashiCorp, said despite the growing number of open source service mesh alternatives, many organizations would prefer to employ a service mesh provided by a single vendor that they didn’t have to provision and maintain. HashiCorp’s Consul service mesh provides a lightweight alternative that enables service-to-service networking and security via connection authorization and encryption and spans both Kubernetes clusters and virtual machine platforms using the mutual Transport Layer Security (mTLS) protocol.

    Applications can then employ sidecar proxies in a service mesh configuration to establish TLS connections for inbound and outbound connections without ever having to directly interface with Consul itself.

    HashiCorp is making the case for Consul at a time when internecine warfare is raging between proponents of open source service mesh platforms such as Istio, Linkerd and Kuma. The Consul service mesh provides an alternative that is simpler for developers to incorporate across both microservices-based applications running on a Kubernetes cluster and legacy monolithic applications running on virtual machines, Kent said. In contrast, Istio and Linkerd are designed solely for use in Kubernetes environments.

    It’s still the early days of service mesh adoption. In addition to simplifying application traffic routing between services, one of the other benefits of service mesh is that it provides a layer of abstraction above lower-level network application programming interfaces (APIs) and protocols that is more accessible to developers. As developers become more familiar with service meshes, the ability to programmatically include network and security operations within a DevOps workflow will grow. HashiCorp is collectively positioning Consul and Vault as foundational components for creating a zero-trust architecture.

    In the meantime, each IT organization will need to determine which type of service mesh makes the most sense for their environment. In many cases, organizations may find themselves employing multiple service meshes to address different use cases. Regardless of which they choose, service meshes will soon become a permanent fixture in the proverbial solar system around which IT services revolve.

    HashiCorp claims that more than 2,000 organizations signed up to participate in the HCP Consul and HCP Vault beta programs. That level of interest suggests interest is growing in consuming IT as a service rather than as a platform that requires deployment by an internal IT team. It remains to be seen the degree to which organizations will prefer to consume those services directly from a vendor, versus a cloud service provider or third-party IT services provider.

  • The State of Digital Innovation, One Year Into the Pandemic

    The State of Digital Innovation, One Year Into the Pandemic

    It’s obvious COVID–19 accelerated digital reliance for many companies. And it’s no surprise that, according to a recent study, 89% of tech leaders believe digital experiences are critical to addressing new COVID–19 challenges. In this race toward 100% digital business, agile innovation is the new elixir of life — without it, a company may face an early retirement.

    Kong just released their 2021 Digital Innovation Benchmark, which summarizes the tech priorities of 400 IT leaders. The findings stress the importance of rapid digital innovation, open source, microservices architectures, and high quality practices for scaling today’s application ecosystems. Here are the key points technology leaders need to know to remain competitive.

    Innovate or Dissipate

    The urgency to innovate is increasing. According to the survey, 84% of respondents predict a business will go under within six years if they lag behind in digital innovation. Fifty one percent of tech leaders believe their business can only survive three years.

    If digital transformation happens too slowly, it can pose an existential threat. But there are many factors that can hinder faster digital innovation; the complexity of using multiple tech stacks, reliance on legacy IT and lack of automation. Not only are there internal woes, but external danger — 62% of respondents worry about failing to keep up with competitors who innovate faster.

    It seems the urgency has increased over the last year. In last year’s report, just 37% reported they’d be out of business in three years if they didn’t keep pace with digital innovation. That figure rose to a whopping 51% in 2021.

    COVID Amplifies Digital Drive

    Virtually no one is anticipating a decreased IT budget in light of COVID–19. On the contrary, long-term digital transformation efforts are well on target at the majority of institutions, and 75% expect to see an increase in IT/developer budgets over the next 12 months.

    Interestingly, when it comes to securing the digital-only economy, European tech may have a head start. Only 40% of European tech companies have increased their security focus, compared to 51% in the U.S. This could be due to previous investment in security and stricter regulation in European countries.

    In terms of cloud adoption, 40% of tech leaders feel COVID–19 has accelerated their move to the cloud. Nearly 40% say the pandemic has encouraged the use of microservices and cloud native architecture.

    Quality Outweighs Speed

    When gauging what matters most to tech leaders, “improving operational efficiency” is still a top priority. However, this year’s report saw a spike in respondents saying application performance and reliability, as well as application security, were moving up the priority list. Though 3 in 5 (62%) respondents said they are “extremely concerned” about competition from speedier rivals, application stability outweighs the collective drive to innovate.

    These trends are likely indicative of a notable rise in cybercrime. As I’ve covered previously, to respond to emerging threats, DevSecOps practices and new security tooling are shifting left within the development cycle, automating things like vulnerability detection. Simultaneously, roles to increase application integrity, like site reliability engineers, are in high demand.

    New Technologies and Open-Source Thrills

    As mentioned earlier, IT budgets are increasing across the board. When adopting new technologies, companies place the highest emphasis on the tech that increases efficiency. A surge in automation follows a low-code movement gaining steam. Companies consider the following key factors when introducing new tech: reducing deployment risk, increasing collaboration, and increasing development. Ninety five percent of US respondents also listed the “need to integrate with existing tools” as necessary — no surprise in today’s API-driven development landscape.

    Ninety one percent of organizations use open-source software in 2021 — this is up from 82.5% in 2020. Across the board, open-source is intrinsically embedded into most software projects. We see open-source especially used in open databases, infrastructure automation, API design and testing, CI/CD tools, Docker containers, Kubernetes and service mesh. Arguably, modern DevOps would not be possible without such open source initiatives.

    Bring it on, Microservices

    If you haven’t heard of microservices yet, we would be worried. An impressive 87% of survey participants believe that microservices-based applications are the future.

    While that sounds substantial, a path toward 100% distributed microservices architecture has not been mapped within most organizations. In 2021, only 33% of companies have transitioned entirely to a distributed architecture, whereas most (53.5%) adopt a hybrid mix of microservice and monolithic styles.

    “This is strong evidence that microservices have quickly become the de-facto approach for modern application architectures that enable digital innovation,” the report said. Though more development is required, a microservices-centric future seems obvious.

    Within organizations that have already adopted a microservices approach, the average number of microservices in production is 102. And those are primarily to increase security. Ironically, the report also found maintaining security to be the top challenge of deploying a microservices system. Other drivers for microservices adoption include integrating new tech, increasing development speed and boosting flexibility.

    Kubernetes Becomes Ubiquitous

    Kubernetes has clearly emerged as the industry standard orchestration platform. Eighty six percentof all respondents report they now use Kubernetes in production, or plan to within 12 months. This is a massive jump from VMWare’s 2020 report, which put Kubernetes use at 48%.

    However, there are challenges to implementing Kubernetes in practice. Companies cite security, complexity, performance and monitoring as top setbacks when introducing Kubernetes. To say Kubernetes has a steep learning curve may be an understatement, as abstraction layers are introduced to rectify a widening knowledge gap.

    Service Mesh Prickly for Early Installs

    Interestingly, API gateway adoption and container usage, according to the survey, are both 38%. Yet, service mesh adoption is only at 20%. This could underscore the fact that service mesh is still an emerging concept — service mesh experts say the tech isn’t ready for widespread adoption. Or, it could reflect that production use cases are rare (primarily for supporting vast microservices deployments).

    Early service mesh adopters see increased service connectivity and discovery as a top benefit of the technology. This seems logical, as service mesh aims to be a common networking framework. Other common benefits include cost reduction, meeting compliances, zero-trust security in networking and traffic observability.

    Naturally, service mesh isn’t without its thorns. Complexity in deployment and ensuring performance at scale top the list of challenges faced when deploying service mesh, slowing its adoption.

    Hybrid Multicloud

    The current status of multicloud deployment sees a mix of on-premises and multiple cloud providers, with 41% of organizations using multicloud deployment strategies. While cloud adoption rates are increasing, 31% of organizations are still running on-premises servers. The saturation of cloud tooling, and the market validity of Azure and Google Cloud Platform to take on AWS, have influenced a multicloud environment. Cloud expertise is now a hot commodity to navigate multicloud modalities — so much so that some companies have introduced a new role, The Other CFO, or Cloud Economist, to balance the cloud checkbook.

    Riding out the Virtual Wave

    The pandemic has accelerated the move toward digital experiences, and in turn, quickened the pace of enterprise technological evolution across the board. As COVID–19 effects continue, there’s no indication the virtual wave will recede anytime soon.

    To summarize the current state of digital innovation:

    • Rising digital tide: The pace to innovate is rising, and those left below the new-digital-normal water line will drown.
    • IT spend is up: Most companies have increased IT budgets moderately to support new digital norms.
    • Needs for adoption: Desires for automation, speed, security and integration rank high for adopting new tech.
    • Microservices on fire: The report describes “accelerated mainstreaming of microservices.” Microservices, and the tech that supports them, are clearly the future.
    • Kubernetes everywhere: As Kubernetes rises to ubiquity, last-mile efforts center on security and developer usability.
    • Bullish on service mesh: Service mesh sees early production uses, which will likely signal more growth in this area.

    There’s nothing unexpected in these findings; instead, they affirm what most of us already know — digital innovation is going full throttle. Check out the entire 2021 Digital Innovation Benchmark here.

  • Thread is the Future of Wireless Mesh

    Thread is the Future of Wireless Mesh

    Over the last decade or so, interest in IoT technology and connecting devices to one another, and to the internet, has increased. Of course, one of the key elements necessary to connect devices is wireless communication. There are several wireless interfaces, such as cellular, Wi-Fi, Bluetooth, ZigBee, LoRa etc., that are prominently used in different industries to make these connections. However, choosing the right wireless technology is vital for the success of any product. One should consider several factors before zeroing in on the right wireless technology for your goals. Some of the factors to consider include:

    • Wireless range/ coverage
    • Throughput
    • Power consumption
    • Scalability
    • Security
    • Ease of provisioning

    Selecting the right technology to get the best results and satisfy all your requirements is a challenge, and what’s “right” may vary depending on use case. For instance, cellular technology is often preferred for a mobile device used in logistics applications, as it has excellent coverage. However, cellular technology is power-hungry; it would be difficult for the battery-powered device to operate for long periods of time. Similarly, LoRa, with a wide wireless range and low power consumption, is an excellent choice for applications such as smart metering. But it has a relatively low data throughput, and therefore may not be the ideal choice for certain industrial applications.

    What is Thread?

    One of the recent entrants to the wireless communication space is Thread. Thread is an IPv6-based, low-power, open source, mesh networking protocol for connected devices, backed by Nest Labs (a subsidiary of Google) and other industry bigwigs. Like ZigBee, it uses IEEE 802.15.4 wireless mesh protocol, but, being internet protocol (IP)-based means a Thread network can seamlessly connect to the internet without needing a translator or a gateway in between. Thread operates on the 2.4GHz ISM radio band, the same as ZigBee, and offers a throughput of 250 kbits/s with a typical range of about 30 meters. It employs spread-spectrum techniques to provide immunity to interference. Thread’s low power consumption means that a coin cell could power it for almost two years.

    Thread as a Mesh Network

    As a mesh network, Thread can have several hundred devices communicating with each other and the cloud. A typical Thread network would consist of an endpoint device, router node and a border router. A typical endpoint would be a battery-powered device that communicates with a parent router. A router node would receive packets from devices on the network and forward them to the rest of the network. The border router is a device that facilitates communication between a Thread network and a non-Thread network, such as Wi-Fi or Ethernet, by forwarding packets.

    Benefits of Thread

    Because Thread is a self-healing mesh network, it offers many benefits. One is avoidance of a single point of failure. That is, if any router in the network fails, another router automatically takes its place. Unlike ZigBee, for example, Thread devices can be linked to multiple border routers, making the network more reliable. Another advantage is that, being mesh, the Thread network is highly scalable. Each Thread network can scale to hundreds of devices. Thread also benefits from being built on IPv6 to take advantage of end-to-end routing and addressability. Any two IPv6 endpoints, whether on the same Thread mesh or across networks, can communicate, end-to-end, with easy and well-understood internet routing mechanisms moving packets from one endpoint to the other.

    One of the biggest benefits of Thread is that it can provide a high level of security. Security breaches associated with IoT and connected devices are on the rise, and are a major barrier to legacy device connectivity. All devices in a Thread network are automatically authenticated and communication is encrypted. Thread networks use a secure, financial-class encryption and the technology has plugged the obvious security loopholes found in other wireless protocols.

    An IoT device should be easy to deploy in the field, which is another factor in selecting the right wireless technology. Thread devices can be easily set up using a smartphone or a tablet. Users can securely connect devices to each other, and to the cloud, for easy control and access from anywhere.

    Thread is built on 6LoWPAN, which is the same radio protocols as that of ZigBee; an IEEE 802.15.4-based specification for high-level communication used to create personal area networks with digital radios. It’s possible that, with just a software upgrade, an existing ZigBee module can be converted to a Thread module. For legacy ZigBee users, it would be relatively easy to migrate to Thread technology. Availability of OpenThread, an open-source implementation of Thread, is likely to accelerate the development of products that leverage Thread. However, the limited availability of off-the-shelf border routers, and the use of less preferred mesh topology, is a challenge for its adoption into IoT devices.

    The Future of Service Mesh

    Thread has great potential, and can be considered a very good alternative to existing wireless communications options with the added benefit of Wi-Fi-like features. Because it’s open source and backed by large semiconductor manufacturers and technology heavyweights, Thread technology is poised to gain substantial momentum over the next few years. It may eventually emerge as the primary choice for medium throughput, low power IoT applications.

  • HAProxy Updates Data Plane API to Simplify Service Discovery

    HAProxy Updates Data Plane API to Simplify Service Discovery

    HAProxy has updated the open source HAProxy Data Plane application programing interface (API) to include service discovery capabilities alongside native support for the Consul service mesh being developed by HashiCorp.

    Version 2.2 of the HAProxy Data Plane API also adds support for file handling, SSL certificates, map files and configuration files for its Stream Processing Offload Engine (SPOE).

    HAProxy is best known for the open source load balancing software of the same name that is widely deployed by DevOps teams. As an extension of that platform, HAProxy Data Plane makes it possible to dynamically add and configure front ends and back ends and then route application traffic between them.

    Daniel Corbett, director of product and marketing for HAProxy, said the HAProxy load balancing software coupled with the Data Plane allows IT organizations to create a gateway through which they can manage their APIs.

    Corbett said the company is currently rounding out a suite of offerings, dubbed HAProxyOne, that are extensions to its load balancing software and that add a control plane and a service mesh to its portfolio. The company has already added a Kubernetes ingress controller to its portfolio.

    At the same time, however, HAProxy Data Plane will make it simpler for DevOps teams to integrate other offerings, such as Consul, within the control plane being developed by HAProxy, Corbett says.

    Corbett said, collectively, HAProxy will provide a suite of tools through which DevOps teams will be able to more easily manage application delivery across IT environments that span multiple platforms.

    HAProxy is not the only load balancing software provider with similar ambitions. The issue that HAProxy will address is the need for a framework that can apply equally well to both monolithic applications and microservices-based applications, Corbett says.

    In 2021, a major battle is brewing for control over the infrastructure that DevOps teams use to deploy applications at scale. Alongside proxy servers and load balancing software, IT organizations are starting to use API gateways, service meshes and ingress controllers as the number of APIs through which data flows rapidly increases. In effect, these technologies provide the connectivity infrastructure required to route data between the applications that make up a distributed computing environment.

    It’s still early days, though, as advocates for competing open source projects make their cases for the hearts and minds of developers. However, given the profound impact these decisions are likely to have on IT operations, it’s likely many organizations will soon standardize on one suite of offerings to minimize complexity.

    Whatever the result, applications environments are, in fact, becoming more complex. IT organizations will soon find themselves running monolithic applications alongside a raft of microservices-based applications, all of which need to use APIs to integrate with each other. Decisions made today about how best to integrate those APIs will have a profound impact for years to come.

  • How Service Mesh Enables a Zero-Trust Network

    How Service Mesh Enables a Zero-Trust Network

    How can we achieve high-grade security within a microservices ecosystem? Service mesh may be the answer

    Enterprise applications often assign an identity to humans to determine security clearances. Using standards such as OpenID Connect and SAML, we can delegate authorization scopes across a suite of applications to determine precisely what a user is permitted to do. But what about the applications themselves? Some believe that microservices should follow this identity-first approach, too.

    For large-scale application ecosystems, microservices is arguably more secure than a monolith. As Marco Palladino, CTO of Kong, described, “A monolithic application is a security incident waiting to happen.” Yet, microservices shouldn’t necessarily trust one another. So, how can we achieve high-grade security within a microservices ecosystem?

    The answer may lie in service mesh. I recently met with Palladino to discover how a service mesh can achieve bank-grade security for established and emerging microservices patterns. Similar to how enterprises assign an identity to end users, a zero-trust security network gives an identity to microservices themselves.

    A Zero Trust Network Trusts Nothing

    With more personal data used in cloud operations, more and more personally identifiable information (PII) is vulnerable to attack, and the costs are high. In Q1 2019, the cost of breaches in the financial sector was $6.2 billion. In 2018, 97% of breaches exposed PII, a top target for cybercriminals.

    Organizations are thus feeling pressure to secure their assets. The most precious data is held within financial services and health care, where GDPR and HIPPA enforce strict accordance with data privacy. This pressure is leading U.S. banks to clamp down third-party application access. Simultaneously, European banks face similar security dilemmas while appeasing PSD2 regulation for open banking.

    To safeguard user data, organizations are adopting a zero-trust security model. “Zero trust security means that we’re not trusting anybody,” said Palladino. “We don’t trust our own services. We don’t trust our own team members.”

    Placing too much trust in users, services and teams could cause a catastrophic failure. And, “there is no bigger risk than thinking you are secure, while in reality, you are not,” he said.

    Monolith ⮕ Microservices

    In practice, architecting a zero-trust application network runs parallel with the trend toward microservices designs. Though it may seem counterintuitive, a microservices system is arguably more secure than a monolithic architecture.

    In a monolithic application, every resource—whether invoices, billing orders or transaction history—is always just one line of code away. Since everything is connected, you could expose a resource with a single access.

    A microservices architecture decouples applications into separate services, each responsible for specific resources that make up the smaller applications, which can be secured and provisioned over a network.

    Segmenting the service landscape avoids one cascading defect affecting all applications. It also enables more control. “By decoupling from monolith to microservices, we can apply fine-grained security permissions and rules to determine what’s possible in the context of the application,” Palladino said.

    Microservices ⮕ Service Mesh

    Implementing these permissions is where a service mesh comes in. The application teams often build security, yet it’s generally bad practice to build your own cybersecurity. Security for microservices requires high expertise, and standardizing connectivity between various microservices can easily result in fragmented security implementations.

    Instead of building your own security infrastructure, Palladino recommended utilizing service mesh. By using service mesh as a control plane for microservices, platform architects can specify specific rules and attributes to generate an identity on a per-service basis.

    Service mesh also removes the burden of networking from developers, enabling them to focus more on their core logic. “Application teams become consumers of connectivity, as opposed to the makers to this connectivity,” Palladino noted.

    Identity for Services

    In the same way enterprises create identity profiles for humans, Palladino said we must extend the same model to services, pairing each service with authorization scopes. “Services must provide their own identity,” he noted. “Based on that, they can do certain operations in their infrastructure.”

    When we think of identity for services, attributes such as geographic location and certificates come to mind. These and other traits could make up a microservice’s authorization scopes. Utilizing a service mesh, architects could assign such attributes to each workload and service to determine what operations are allowed or what requests can be made to what other services.

    For example, services from one region could be designed not to consume services from another region. Such attribute-based control for microservices is a novel, well-needed strategy, Palladino said. “It was crazy this was not in place before; not having zero trust is like having all your money in an open vault.”

    Best Practices for Service Identity

    Knowing that we want to implement identity-based security for microservices, where are some best practices? Palladino recommended:

    • Automate some attributes: A service mesh could automatically assign identity attributes upon creation, such as cloud zone or geographic boundaries.
    • Provide a way to manage attributes: A dashboard would be necessary for DevOps engineers to create, edit or delete service-level attributes.
    • Governance: Architects must manage the control plane and create identities for the right parties to access this capability.
    • Secure encryption and Mutual TLS: Teams will require a system for rotating and expiring certificates for hundreds of thousands of workloads running across an organization, noted Palladino.
    • Standardize: Secure Production Identity Framework For Everyone (SPIFFE), a CNCF incubating project, is a good framework for service identity, making it operable with other cloud-native projects.
    • Play nice with CI/CD: Attribute creation could be hooked into an underlying CI/CD process to occur when deploying products automatically.

    Once microservices have identities, the services they interact with can determine what actions they are authorized to perform. This limits machine-to-machine communication to allowed operations.

    Zero-Trust Security With One Click

    Many teams have transitioned to a microservices architecture to deploy more often, be more distributed, decoupled or improve overall reliability. While these innovations are largely positive, Palladino cautioned against innovation without the proper security forethought: “It’s silly to transition to a microservices strategy without thinking about how these services are secured,” he said.

    Teams will also be running microservices on various environments—VMs, cloud or physical data centers. Thus, considering microservice-to-microservice communication, how do we route traffic between such environments? How do we observe metrics and logs? Palladino believes an agnostic service mesh that supports multi-region, multi-zone, multi-cloud and hybrid modes is the answer to these dilemmas.

    If used correctly, service mesh can plug security gaps for internal service-to-service communication, thus obfuscating high-value resources, such as financial services data, from nefarious players. The key to solving the service identity challenge is a usable dashboard. As Palladino described, “Zero trust security with one click.”

  • SRE Anxiety

    SRE Anxiety

  • NGINX Expands Portfolio to Include Service Mesh

    NGINX Expands Portfolio to Include Service Mesh

    NGINX at its online Sprint conference today launched a bevy of offerings including a service mesh as part of an expanded effort to meld network and security operations within the context of a larger DevOps workflow.

    Rob Whiteley, chief marketing officer for the subsidiary of F5 Networks, said NGINX Service Mesh 1.0 provides an easier alternative to deploy a service mesh based on the open source NGINX proxy server software already widely employed in enterprise IT environments. That lighter-weight service mesh is also integrated with the NGNIX ingress controller to enable it to be employed across microservices spanning both legacy virtual machine environments and Kubernetes clusters, he said.

    In general, Whiteley noted, most organizations will not need a service mesh unless they are looking to integrate more than a thousand microservices. If an organization only has hundreds of microservices, an ingress controller should suffice, and anything involving less than a hundred microservices can be handled by proxy software.

    NGINX Service Mesh 1.0 will be offered by NGINIX and F5 Networks will continue to offer a service mesh based on the Istio project for Kubernetes environments that relies on Envoy proxy software, which is not as lightweight as the NGINX platform, noted Whiteley. DevOps teams will have to decide which service mesh to deploy.

    In the meantime, NGINX is also updating its NGINX Controller to add support richer analytics, a declarative application programming interface (API) for continuous integration/continuous delivery (CI/CD) integration, role-based access controls and enhancements to the developer portal for API management.

    NGINX is also driving tighter integration between Controller and NGINX App Protect, a web application firewall that will inherit the API, analytics and self-service capabilities of Controller. NGINIX App Protect is also now being integrated with NGINX Ingress Controller for Kubernetes. The Controller App Security tool that enables those integrations is in private beta now, with general availability expected by end of 2020.

    Finally, NGINX is now leveraging services made available by F5 Networks via software-as-a-service (SaaS) platforms in the form of NGINX Analytics Cloud, which replaces NGINX Amplify. That capability will be available in the first quarter of 2021.

    In general, Whiteley said NGINX is trying to serve the needs of traditional network operation teams that want to provide self-service capabilities to development teams as well as via programmatic interfaces to DevOps teams. In many cases, enterprise IT organizations are employing both approaches to expose network services, noted Whiteley.

    Of course, the issue that ultimately might drive the convergence of NetOps and DevOps is the rise of the service mesh. In addition to integrating microservices, the service mesh provides developers with a consistent set of interfaces for invoking network and security services spanning a dizzying array of servers and appliances. As that transition occurs, IT teams will become much more agile than they are today. The challenge, of course, will be melding network operations and DevOps cultures that today don’t have all that much in common.