devopsy.kinsta.cloud

Category: Microservices Journal

  • How Service Mesh Addresses 3 Key Microservices Challenges

    How Service Mesh Addresses 3 Key Microservices Challenges

    I was recently reading the “Global Microservices Trends” report by Dimensional Research and found myself thinking, “A service mesh could help with that.” Let’s look at three key challenges listed in the report.

    A couple key points in the report make it clear microservices are seeing widespread adoption. It’s also clear that along with the myriad benefits they bring, there are also tough challenges that come as part of the package. From the report:

    • 91 percent of enterprises are using microservices or have plans to.
    • 99 percent of users report challenges with using microservices.

    Major Microservices Challenges

    The report identifies a range of challenges companies are facing.

    Companies are seeing a mix of technology and organizational challenges. We’ll focus on the technological challenges a service mesh solves, but it’s worth noting that one thing a service mesh does is bring uniformity so it’s possible to for all teams to have the same view, reducing the need for certain skills.

    Each Additional Microservice Increases the Operational Challenges

    Not with a service mesh! A service mesh provides monitoring, scalability and high availability through APIs instead of using discrete appliances. This flexible framework removes the operational complexity associated with modern applications. Infrastructure services were traditionally implemented as discrete appliances, which meant going to the actual appliance to get the service. Each appliance is unique, which makes monitoring, scaling and providing high availability difficult. A service mesh delivers these services inside the compute cluster itself through APIs and doesn’t require any additional appliances. Implementing a service mesh means adding new microservices without adding complexity.

    It is More Difficult to Identify the Root Cause of Performance Issues

    The service mesh toolbox gives you a couple of things that help solve this problem:

    Distributed Tracing: Tracing provides service dependency analysis for different microservices and tracking for requests as they are traced through multiple microservices. It’s also a powerful way to identify performance bottlenecks and zoom into a particular request to identify which microservice contributed to the latency of a request or which service created an error.

    Metrics Collection: With service mesh you also get the ability to collect consistent metrics across your mesh. Metrics are key to understanding what has happened in your applications, and when they were healthy compared to when they were not. A service mesh can gather telemetry data from across the mesh and produce consistent metrics for every hop. This makes it easier to quickly solve problems and build more resilient applications.

     

    Differing Development Languages and Frameworks

    Another major challenge that report respondents noted facing was the challenge of maintaining a distributed architecture in a polyglot world. When making the move from monolith to microservices, many companies struggle with the reality that, to make things work, they have to use different languages and tools. Large enterprises can be especially affected by this, as they have many large, distributed teams. Service mesh provides uniformity by providing programming language agnosticism, which addresses inconsistencies in a polyglot world where different teams, each with its own microservice, are likely to be using different programming languages and frameworks. A mesh also provides a uniform, applicationwide point for introducing visibility and control into the application runtime, moving service communication out of the realm of implied infrastructure, to where it can be easily seen, monitored, managed and controlled.

    Microservices are cool, but service mesh makes them ice cold. If you’re on the microservices journey and are finding it difficult to manage the infrastructure challenges, a service mesh may be the right answer. Let me know if you have any questions on how to get the most out of service mesh, I’m happy to talk and you can find me @zjory.

    — Zach Jory

  • Containers, Service Mesh and API Gateways: It Starts at the Edge

    Containers, Service Mesh and API Gateways: It Starts at the Edge

    Anyone embracing container technology such as Docker or Kubernetes has no doubt heard about the associated next big thing: service mesh, which promises to homogenize internal network communication between microservices and provide cross-cutting nonfunctional concerns such as observability and fault-tolerance. However, the underlying proxy technology that powers a service mesh also can provide a lot of value at the edge of your systems—particularly within an API gateway.

    Although it may appear that service mesh technologies have suddenly sprung up overnight, the reality is that many organizations have been using what we now identify as a service mesh for quite some time (including Verizon, eBay and Facebook). One such organization is Lyft, a U.S.-based ride-sharing service with a $1 billion annual revenue. Lyft also happens to be the creators of the open source Envoy proxy that is powering a lot of development in the service mesh space, such as the Kubernetes-native Istio control plane and Ambassador API gateway.

    The State of SOA Networking

    In a talk last year, Matt Klein, one of the creators of the Envoy Proxy, described the state of service-oriented architecture (SOA) and microservice networking in 2013 as “a really big and confusing mess.” Debugging was difficult or impossible, with each application exposing different statistics and logging and providing no ability to trace how requests were handled throughout the entire services call stack that took part in generating a response. There was also limited visibility into infrastructure components such as hosted load balancers, caches and network topologies.

    “It’s a lot of pain,” he said. “I think most companies and most organizations know that SOA [microservices] is kind of the future and that there’s a lot of agility that comes from actually doing it, but on a rubber meets the road kind of day in and day out basis, people are feeling a lot of hurt. That hurt is mostly around debugging.”

    Maintaining reliability and high-availability of distributed web-based applications was a core challenge for large-scale organizations. Solutions to the challenges frequently included either multiple or partial implementations of retry logic, timeouts, rate limiting and circuit-breaking. Many custom and open source solutions used a language-specific (and potentially even framework-specific) solution that meant engineers inadvertently locked themselves into a technology stack “essentially forever.” Klein and his team at Lyft thought there must be a better way. Ultimately, the Envoy proxy project was created to be this better way.

    Working Outside-In: Edge Proxy Benefits

    Although the open source release of the Envoy Proxy project made Klein and the Lyft engineering team look like an overnight success in September 2016, the reality was that the journey was filled with challenges over the four years from the initial hybrid-SOA Lyft architecture to their current microservice- and service mesh-enabled system. In a more recent talk at the 2017 Microservices Practitioner Virtual Summit, Klein talked about the essential need for—and associated challenges of—demonstrating business value for a technology-focused migration toward a service mesh network topology.

    Klein’s first piece of hard-won advice was, “Start with [an] edge proxy.” Microservice-based web applications need edge reverse proxying to avoid both the exposure of the internal business service interfaces (which would violate the principle of loose coupling) and the high operational overhead of exposing each service via an independent URI or RPC endpoint. Existing cloud offerings are “not so good” in this edge proxy or gateway space, or are presented to engineers as a potentially confusing range of differing products. Instead, Klein recommended starting an implementation of modern proxying technology at the edge, as this provides business value in the form of improved observability, load balancing and dynamic routing. Once an engineering team has understood how to operate proxy technology at the edge, the benefits can be rolled inward toward ultimately creating an internal service mesh.

    Evolution of the Edge: From Proxies to API Gateways

    AppDirect, an end-to-end commerce platform for managing cloud-based product and services with an estimated $50 million annual revenue, has undertaken a similar journey to Lyft, as highlighted in a recent blog post, “Evolution of the AppDirect Kubernetes Network Infrastructure.” The dynamic and ephemeral nature of cloud technology and container orchestrators such as Kubernetes, which provide many benefits in terms of scalability and resilience, mean that they are additional challenges for exposing public endpoints for business functionality provided via a composite of microservices.

    The AppDirect engineering team took a measured approach to solving these challenges, beginning with making core parts of the configuration static (such as service ports exposed) and placing a load balancer in front of each application. Their second iteration embraced more dynamism using HashiCorp’s Consul distributed key/value store and the HAProxy reverse proxy that supported “hot reloading” of configuration as it changed at runtime. Ultimately, however, the team were keen to leverage the richer functionality provided by a more fully featured API gateway.

    “The goal of our API gateway was to leave the exposed public APIs untouched and accessible even to legacy URLs and partner-customized domains, yet allow us to grow by ‘injecting’ and replacing old components one by one,” according to the blog post.

    After evaluating a series of open source and commercial offerings the AppDirect team deployed the Kubernetes-native Ambassador API gateway, which builds upon the Envoy proxy:

    “Relying entirely on the Kubernetes native API—which we know and love—Ambassador is lightweight, stateless, and uses no external datastore. Ambassador exclusively makes use of Kubernetes annotations to drive the active route configuration (i.e., it is the control plane of Envoy’s data plane),” the team noted in the blog post.

    Although AppDirect has not fully implemented a service mesh for internal communication, the company is already learning about the benefits of technology like the Envoy proxy and, critically, how to handle deployments of this in production.

    Making Sense of it All

    The adoption of service mesh technology within cloud native implementations and migrations is only just beginning, but it is already possible to identify that this technology fills a gap currently identified with modern container-based application platforms such as Kubernetes. All of the benefits of a service mesh—such as rate limiting, circuit-breaking and observability—also can be leveraged at the edge of systems. If you want to explore and learn about this technology, starting at the edge of your systems and working inward can be an effective strategy. This can also allow the technology to demonstrate value, such as improved observability and resilience, earlier than attempting to work inside out.

    — Daniel Bryant

  • Knowing What Your Microservices Are Doing

    Knowing What Your Microservices Are Doing

    Microservicin’ ain’t easy, but it’s necessary. Breaking your monolith down into microservices is a must in a cloud-native world, but it doesn’t automatically make everything easier. Some things actually become more difficult. An obvious area where it adds complexity is communications between services; visibility into service to service communications can be hard to achieve, but is critical to building an optimized and resilient architecture.

    The idea of monitoring has been around for a while, but observability has become increasingly important in a cloud-native landscape. Monitoring aims to give an idea of the overall health of a system, while observability aims to provide insights into the behavior of systems. Observability is about data exposure and easy access to information which is critical when you need a way to see when communications fail, do not occur as expected or occur when they shouldn’t. The way services interact with each other at runtime needs to be monitored, managed and controlled. This begins with observability and the ability to understand the behavior of your microservices architecture.

    A primary microservices challenge is trying to understand how individual pieces of the overall system are interacting. A single transaction can flow through many independently deployed microservices, or pods, and discovering where performance bottlenecks have occurred provides valuable information.

    It depends who you ask, but many considering or implementing a service mesh say that the No. 1 feature they are looking for is observability. There are many other features a mesh provides, but those are for another blog. Here, I’m going to cover the top observability features provided by a service mesh.

    Tracing

    An overwhelmingly important thing to know about your microservices architecture is specifically which microservices are involved in a user transaction. If many teams are deploying their dozens of microservices, all independently of one another, it’s difficult to understand the dependencies across your services. Service mesh provides uniformity, which means tracing is programming language-agnostic, addressing inconsistencies in a polyglot world where different teams, each with its own microservice, can be using different programming languages and frameworks.

    Distributed tracing is great for debugging and understanding your application’s behavior. The key to making sense of all the tracing data is being able to correlate spans from different microservices related to a single client request. To achieve this, all microservices in your application should propagate tracing headers. If you’re using a service mesh such as Aspen Mesh, which is built on Istio, the ingress and sidecar proxies automatically add the appropriate tracing headers and report the spans to a tracing collector backend. Istio provides distributed tracing out of the box, making it easy to integrate tracing into your system. Propagating tracing headers in an application can provide nice hierarchical traces that graph the relationship between your microservices. This makes it easy to understand what is happening when your services interact and if there are any problems.

    Metrics

    A service mesh can gather telemetry data from across the mesh and produce consistent metrics for every hop. Deploying your service traffic through the mesh means you automatically collect metrics that are fine-grained and provide high-level application information since they are reported for every service proxy. Telemetry is automatically collected from any service pod providing network and L7 protocol metrics. Service mesh metrics provide a consistent view by generating uniform metrics throughout. You don’t have to worry about reconciling different types of metrics emitted by various runtime agents or add arbitrary agents to gather metrics for legacy apps. It’s also no longer necessary to rely on the development process to properly instrument the application to generate metrics. The service mesh sees all the traffic, even into and out of legacy “black box” services, and generates metrics for all of it.

    Valuable metrics that a service mesh gathers and standardizes include:

    • Success rates.
    • Request volume.
    • Request duration.
    • Request size.
    • Request and error counts.
    • Latency.
    • HTTP Error codes.

    These metrics make it easier to understand what is going on across your architecture and how to optimize performance.

    Most failures in the microservices space occur during the interactions between services, so a view into those transactions helps teams better manage architectures to avoid failures. Observability provided by a service mesh makes it much easier to see what is happening when your services interact with each other, making it easier to build a more efficient, resilient and secure microservice architecture.

    — Zach Jory

  • Microservices Momentum Accelerates

    Microservices Momentum Accelerates

    A global survey of 353 application development professionals conducted by Dimensional Research on behalf of LightStep, a provider of application performance management (APM) tools, finds a full 86 percent of respondents expect microservices to be the default architecture within five years.

    A total of 60 percent of respondents said they already have microservices in production or deployed as part of a pilot, and 92 percent said they expect to grow their use in the coming year.

    Top reasons cited for employing microservices are agility (82 percent) and scalability (78 percent).

    The downside of increased reliance of microservices is the need to manage them all. The survey finds 99 percent report challenges in using them. More than half (56 percent) reported that each additional microservice increases operational challenges, and 87 percent of those that have deployed microservices in a production environment reported they are generating more application data.

    To make matters more challenging, a full 98 percent of respondents said they have trouble identifying the root cause of performance issues associated with microservices. More than three-quarters (76 percent) said it also takes longer to resolve issues. In fact, 73 percent said it is more difficult to troubleshoot application performance problems compared to a traditional monolithic application.

    Not surprisingly, just less than three-quarters (74 percent) said they plan to increase investments in microservice performance management tools in the next year.

    LightStep CEO Ben Sigelman said that while microservices come in many forms, advances in how software is developed is clearly coming at a cost. Not only is software becoming more challenging to manage, APM tools are now a prerequisite. Historically, IT organizations only monitored their most mission-critical applications. But the level of dependency each microservice has on others requires a more holistic approach to APM, Sigelman said, noting that IT teams now need to be able to see well beyond the border of any one microservice.

    Challenges associated with managing microservices are not likely to deter organizations from eventually adopting them. The level of agility and resilience inherently built into in a microservices-based application are too high to ignore. But the rate at which they are employed might be impacted. There’s usually a direct relationship between the availability of tooling and expertise and the rate at which any emerging technology gets deployed in a production environment. The good news is advances in machine learning algorithms and other forms of artificial intelligence (AI) should make it easier to manage microservices in the years ahead.

    In the meantime, IT organizations can take some comfort in the fact that developers are being held more accountable for the microservices they build. That level of accountability tends to vary widely by organization. But the end result is generally higher levels of software quality because developers increasingly realize they can’t throw code over the proverbial IT operations wall without it coming back to them. The challenge now is to bridge the historic divide between developers and IT operations teams in a way that works best for everyone concerned.

    — Mike Vizard

  • Time to Rethink Infrastructure Operations in Enterprises

    Time to Rethink Infrastructure Operations in Enterprises

    “Business is technology and technology is business” seems to be the new mantra as the rules of corporate strategy are being rewritten across industries. According to IDC’s survey in 2017, “Two-thirds of global CEOs will have digital transformation as part of their corporate strategy.”  That’s CEOs—not CIOs—who will have digital transformation as part of their corporate and, not IT, strategy.

    time for change

    While digital transformation is not a new phenomenon, making digitization core to the corporate strategy is a fundamental shift for technology teams. Delivery units, or “change the enterprise” teams, have warmed up to new ways of working over the last few years and are already on the learning journey. Most enterprises today have digital or agile transformation initiatives that tend to focus on the “change” aspect significantly. However, the less glamorous “run the enterprise” dimension tends to be forgotten or side-lined in these initiatives.

    The rise of DevOps was meant to bridge the gap between “change” and “run.” However, many DevOps transformation initiatives seem to be taking the same old path of least resistance that agile transformations have historically adopted: by focusing on the “change” and delivery teams.

    As a consequence, the infrastructure and operations teams—or, “run the enterprise” units—are now waking up to the new reality and have far less time to adapt than their “change” counterparts. The big question really is, What does it mean to infrastructure and operations teams when the CEO is now embracing digital transformation?

    This means that the technology infrastructure required to support business strategy requires a combination of the usual consistency and quality that infrastructure and operations have historically focused on—but only with greater speed, innovation, flexibility and customer intimacy. For the first time, business is looking at infrastructure as equal partners on this journey, not as a subservient IT function.

    What Caused This Shift in Thinking?

    Since 2001, there have been four game-changers in technology that have caused this shift in thinking: the Agile Manifesto of 2001, adoption of Cloud by enterprises, rise of startups and the DevOps movement. The world of technology as we know has been going through a tectonic shift as a consequence of these overlapping waves of change.

    Agile and DevOps

    Version One’s 11th “State of Agile” report highlights that 71 percent of organizations have current or planned DevOps initiatives in 2018. While Agile ways focus on effective team structures, value focused mindset and greater business alignment, DevOps has taken the principles to the logical next steps of delivering value by focusing on flow, amplified feedback loops and building a culture of learning and innovation. In addition, full stack automation covering infrastructure, application delivery and release orchestration has really catapulted DevOps into the top initiatives in organizations. In terms of architecture, new constructs such as evolving design, microservices, containers and serverless computing are all redefining technology infrastructure. The rise of these new ways of working is only piling immense pressure on traditional infrastructure organizations to reform and rethink every aspect of their operating model and challenge processes built on a foundation of perceived stability.

    The Startup Way

    Enterprises increasingly are being influenced by the ways of startups and how they are driving rapid innovation. There is a cross-fertilization of people moving to enterprises who are challenging the thinking in these enterprises, especially infrastructure area. Teams are now embracing once considered absolutely alien, if not impossible, concepts such as chaos engineering and anti-fragility.

    Cloud

    The recent RightScale “State of Cloud” report reveals that 97 percent of enterprises are using cloud in 2017. However, only a small share of their workload has actually been moved to cloud, indicating the potential for cloud in the enterprise context. This indicates that enterprises are past the quick wins such as digital front-ends and will now struggle with the difficult areas of their applications—the bulk of the enterprise apps where the traditional infrastructure constraints and mindset rules. Enterprises can tackle this by truly embracing change, thinking big but starting small with experiments and continuous refinement of the every single dimension of the way infrastructure teams operate.

    “Nothing is permanent but change.” The wise and timeless words of Confucius ring true!

    — Aditya Vadaganadam

  • The Road Ahead for Service Mesh

    The Road Ahead for Service Mesh

    If you’re struggling to manage microservices as architectures continue to scale, there’s a good chance you’ve at least heard of service mesh. For the purposes of this blog, I’ll assume you’re familiar with the basic tenets of a service mesh.

    I believe that service mesh is advancing microservice communication to a new level that is unachievable with the one-off solutions that were previously being used. DNS patterns, configuration management and other technologies provide some capabilities such as service discovery, but they don’t provide fast retries, load balancing, tracing and health monitoring. The old approach also requires that you cobble together several things each time rather than bundle everything into a reusable tool.

    While it’s possible to accomplish much of what a service mesh manages with individual tools and processes, the process is a pain in the ass. The image below provides a good idea of how a mesh simplifies the management of microservices.

    Right Around the Corner

    So what’s in the immediate future? I think we’ll see the technology quickly mature and add more capabilities as standard features in response to enterprises realizing the efficiency gains created by a mesh and look to implement them as the standard for managing microservice architectures. Service mesh is likely immature for production deployments, but the road map is progressing quickly and it seems we’ll be to v1 in short order. Security is a feature provided by service mesh, but for most enterprises it’s a major consideration and I see policy enforcement and monitoring options becoming more robust for enterprise production deployments.

    A feature I see on the near horizon—and one that will provide tremendous value—is an analytics dashboard to show insights from the huge amount of telemetry data in a service mesh. I think an emerging value proposition we’ll see is that the mesh allows you to gain and act on data that will allow you to more efficiently manage your entire architecture.

    Further Down the Road

    There is a lot of discussion on what’s on the immediate horizon for service mesh, but what is more interesting is considering what the long term will bring. My guess is that we ultimately come to a mesh being an embedded value-add in a platform. Microservices are clearly the way of the future, so organizations are going to demand an effortless way to manage them. They’ll want something automated, running in the background that never has to be thought about. This is probably years down the road, but I do believe service mesh will eventually be a ubiquitous technology that is a fully managed plug and play config. It will be interesting to see new ways of using the technology to manage infrastructure, services and applications.

    We’re excited to be part of the journey, and are inspired by how users are leveraging service mesh to solve direct problems created by the explosion of microservices and also find new efficiencies with it. I look forward to seeing what the community comes up with that I have not yet even imagined.

    — Zach Jory

  • DevOps and Cloud: A Symbiotic Relationship Aimed at Business Success

    DevOps and Cloud: A Symbiotic Relationship Aimed at Business Success

    DevOps and cloud computing are not mutually exclusive, though their relationship has often been uncertain and confusing from a layman’s perspective. While cloud computing relates to technology and services, DevOps is more about processes and process improvement. However, both DevOps and cloud computing are vital in every organization’s journey toward an effective digital transformation.

    Cloud-centric DevOps Automation

    Cloud computing’s centralized nature enables a standard and centralized platform for DevOps automation. Using a cloud platform resolves issues in centralized software deployment caused by the distributed nature of enterprise systems.

    DevOps objectives including continuous integration (CI) and continuous delivery (CD) are supported by most of the private and public cloud service providers. This ensures centralized governance and control, in addition to reducing the costs associated with DevOps automation on-premises. DevOps utilizes orchestration systems that can proactively monitor the cloud data sets and application workloads. End-to-end automation is a prerequisite for deriving the full advantage from the cloud.

    By expanding the concept of continuous improvement to cloud-based platforms, DevOps ensures lesser system vulnerabilities and greater security.

    DevOps Best Practices for Effective Cloud-Based Computing

    DevOps provides several core capabilities that assist organizations in effectively handling cloud challenges. These include:

    • Infrastructure as Code (IAC): IAC comprises the provisioning of servers and installation of application code, the core components of the system architecture.
    • Automated Application Deployments: DevOps practices facilitate the creation of a fully automated application deployment pipeline that is of great importance in the development life cycle.
    • Application Lifecycle Management (ALM): DevOps principles such as continuous integration and delivery help in effective ALM in the cloud.
    • Continuous Quality Assurance (QA) and Testing: DevOps capabilities address the challenges for QA and testing in the cloud by provisioning multiple test environments using cloud-based resources that result in enhanced quality and productivity.
    • Knowledge-Sharing with the Cloud Provider: DevOps promotes the concept of knowledge sharing between organizations and SMEs of the cloud service providers throughout the application life cycle using online communities that are focused on fostering communication and collaboration, thereby ensuring that most risks are mitigated effectively.

    The Significance of Cloud Computing vis-á-vis DevOps

    Cloud computing complements DevOps in several ways. The application-specific infrastructure in the cloud enables developers to own more components easily and enhance their productivity and efficiency. It allows developers to create the development environments quickly without the need for IT operations to provision resources and infrastructure.

    Cloud computing ensures flexible IT infrastructure in addition to enabling greater business agility. It propels IT transformation by helping organizations in streamlining and embedding DevOps processes.

    DevOps tools and services eliminate human error and help in establishing repeatability by automating and streamlining the process of building and managing code.

    IT Transformation Enabled by DevOps with Cloud Technology

    Cloud computing coupled with DevOps ensures that scalability becomes an integral part of application development, thereby contributing to reduced infrastructure costs and increased global reach.

    Cloud-based operations increase the availability and failover ability of applications in addition to eliminating downtime, which leads to improved business reliability and rise in customer satisfaction.

    DevOps automation and IAC help in reducing the complexity of the cloud and improving system maintenance. Additionally, the automated repeatable processes increase security controls. Process streamlining and faster access to the development environments ensure improved product time to market.

    In Conclusion

    By realizing the importance and prioritizing the usage of DevOps in the cloud, organizations can derive a huge number of potential benefits including enhanced agility and reduced operational costs.

    — Veritis

  • Building a Solid Foundation for Microservices Security

    Building a Solid Foundation for Microservices Security

    It’s often true that threats evolve faster than development practices and technologies can keep up with, which can be seen in the current microservices approach to application development. While microservices bring clear benefits to developers by enabling application deployment via modular, independently deployable services, they also open the door to new security vulnerabilities.

    Consequently, these changes in the approach to software development require a change in the mindset of developers regarding how they think about and implement security. Security now must be a core component of each service—security that can withstand the constantly changing nature of these interactive services. Each service must be a resilient and secure unit that is capable of interacting with other apps and services without compromising security. In addition, each service must be careful how it handles data at the edges to ensure every possible interaction can be secured, even when interacting with services that do not meet the required security standards.

    To fully address these security challenges, developers also need to change their mindset on how they approach privacy and security in their code. That means thinking of security from the genesis of the program and from within the code itself rather than relying on the infrastructure to secure the application. This approach enables developers to start their architectural decision-making by thinking of security as the foundation of their code, instead of as an accessory.

    Security from the Start

    In the bigger picture, DevOps teams must have full awareness and appreciation that there is no single approach to security, and that security and privacy considerations must be addressed case by case. Although there can be more, there are essentially five things that developers can do to make microservices security foundational to the development process.

    Compartmentalization

    First, developers must begin compartmentalizing the software development mission by attempting to make their microservices as essential as possible. Still, developers have to be careful not to go to extremes that result in the creation of a swarm of nanoservices performing a single task. The overall goal is to reduce responsibilities to the point where each single process lacks enough information to be a liability if it were to be breached.

    Encryption

    The role of encryption plays prominently in the new mindset for developers, so it’s imperative to utilize it on all of the data that each microservice needs and sending it on a perishable channel. This allows the cancellation of a compromised communication channel, rotation of the encryption keys used and retrying the message on a different channel or to a different node without worrying about a breach.

    A good example of this is a node where control has been lost in a high availability (HA) layout. By cancelling all message queues and resending the messages with a rotated key, it’s possible to continue functioning without worrying that the unresponsive node could be compromised and avoid a full stop.

    Disposable Channel Signing

    Developers will greatly improve their security posture in the software development life cycle (SDLC) by sending disposable channel signing and encrypting data to the services under their control. This will allow them to cancel credentials, and avoid data leakage, even when the control on the node is lost.

    Different Keys

    Developers are beginning to understand the efficacy in using as many different keys as may be needed since storage is a weak point in terms of encryption. The alternative is to use keys that are rotated regularly. This, however, requires going around the persistence solution and re-encrypting a lot of the data, which is not ideal. Besides, having layers of encryption will ensure that a single leakage from the storage keys will not grant access to plain data. Also, it’s important to use different keys for storage and transport, as re-encrypting on read is easy. This process avoids the need to spread keys and keep it tight.

    Key Access

    Finally, developers will benefit from making sure that all keys allow the minimum possible access while keeping in mind that they will need to tailor the time to live (TTL) as much as possible to the targeted use of each key. Although this approach may result in a complex permission schema, it delivers a massive reduction of the attack surfaces while adhering to security best practices.

    Conclusion

    Some of this may be common sense, and what is useful for one developer might not be sufficient for another. Generally, it’s good for developers to regularly challenge these suppositions on every service that they write, but the above formulated guidelines will serve almost every developer well by providing a stable foundation on which to begin their thinking. The universal viewpoint that they should all be taking is that security must be part of the DNA of their software.

    — Horacio Duran

  • Transition to DevOps Increasing Across IT Firms

    Transition to DevOps Increasing Across IT Firms

    Demand for faster product development and quick market release created a need for increased collaboration between Development (Dev) and Operations (Ops) teams, which eventually led to “DevOps.” With this, transition to DevOps has become one of the key points of discussion across many IT firms. This article gives you an overview of the demand and trend for organizations to transition to DevOps.

    Rise in IT innovation and burgeoning digital revolution have led to the demand for faster development and quicker releases to stand out in the IT competitive scenario. This transition eventually led to a new culture that saw collaboration between two key IT teams, development and operations teams, which the industry calls DevOps.

    DevOps established a new style of IT functioning, easing different phases of software process from product development to testing and final market release, all in a rapid and reliable way.

    Why DevOps Transition?

    Rapid delivery of independent software components and continuous integration of the same with production systems forms the key principle behind DevOps functioning.

    DevOps is often confused with Agile methodology. Though they share similarities in providing improved IT performance through rapid development, DevOps stands apart from Agile because of its efficacy in the software deployment phase, ensuring a constant communication between the two teams. Thus, DevOps is often termed as a successor to Agile.

    A collaborative approach, key for information exchange across the line, is one of the major factors driving firms to undergo DevOps implementation.

    Though DevOps is well-known as a merger of development and operations teams, an effective DevOps model extends beyond that to other key functional areas of organizations.

    Breaking the old trend of limiting individual teams to their respective work domains, DevOps brought in a scope for knowledge-sharing among them, wherein developers can extend themselves to testing and deployment and operations team members can upgrade their skill set, learning new languages, architectures and tools.

    Increased Demand for DevOps Resource

    Transition to DevOps holds a key demand in the fast-growing IT market, wherein managing with the existing infrastructure or resource plays an almost equal role as coming up with something new.

    Greenfield projects aside, DevOps deployment is most often seen in brownfield projects that encourage building on the existing resources.

    With this situation in place, there is also a lot of demand for DevOps resources across firms. The “2017 Open Source Jobs Report” from the Linux Foundation shows 60 percent demand for DevOps human resources among more than 2,000 IT open source professionals and IT hiring managers.

    This clearly shows the level of demand that transition to DevOps is holding in the IT industry.

    “If there isn’t an existing DevOps role within your company, software developers should spend time sitting with the operations team or vice versa to understand how their processes work and how they can be improved through collaboration,” said Mike Durney, CEO of the job-hunting site Dice.

    The report found:

    • Nearly 50 percent of hiring managers are keen about those DevOps resources with professional credentials such as relevant certifications
    • More than 47 percent of the companies are ready to fund certification programs for their existing personnel
    • 42 percent of companies are keen on adding DevOps skills to their hiring portfolio
    • “DevOps Engineer” profile ranks second in Glassdoor’s Best 50 jobs in America

    Despite its advantages, however, DevOps has a few challenges to overcome related to application integration, test automation, budget and skill set, among others.

    — Veritis

  • NATS Messaging Entering Cloud Native Purview

    NATS Messaging Entering Cloud Native Purview

    The Cloud Native Computing Foundation (CNCF) has expanded the scope of its purview by adding open source NATS messaging software to an expanding list of technologies it now oversees.

    NATS messaging software has been commonly employed in environments such as platform-as-a-service (PaaS) environments. But with the rise of microservices, a campaign to make NATS a part of the portfolio of technologies that members of CNCF consortium will advance has begun in earnest, said Derek Collison, who lead the development of NATS and is now CEO of Synadia Communications, which is dedicated to enabling organizations to more easily deploy and manage messaging systems based on NATS.

    The ultimate goal, Collison said, is to not only make messaging ubiquitous, but also effectively invisible.

    Collison said he and the CNCF envision a world where messaging just comes baked into every application. PaaS environments may have driven mainstream adoption of NATS messaging to integrate various elements of an application, but microservices will make messaging a fundamental requirement for building applications that can efficiently scale, he said, adding too many organizations already run into these issues because they are depending on HTTP to integrate various microservices.

    NATS is already widely employed by a number of vendors and organizations including Apcera, Apporeto, Baidu, Bridgevine, Capital One, Clarifai, Cloud Foundry, Comcast, Ericsson, Faber, Fission, General Electric, Greta, HTC, Logimethods, Netlify, Pex, Pivotal, Platform9, Rapidloop, Samsung, Sendify, Sensay, StorageOS, VMware Acadiant, Weaveworks and Workiva.

    The core NATS server and NAT Streaming software are maintained by Synadia. There are clients for Python, Ruby, Node.js, Elixir, Java, NGINX, C and C#, as well as third-party contributions that add support for Arduino, Rust, Lua, PHP, Perl and others.

    Longer term, Collison sees NATS evolving to include functionality to support real-time applications, many of which today are using Apache Kafka software. Rather than having to deploy NATS and Kafka for different use cases, Collison said it will make more sense to have a common control plane to address multiple classes of use cases for messaging.

    Messaging systems in one form or another have been at the heart of integration platforms for decades now. But the assumption was always that integration would be addressed after the applications were deployed. In the future, the assumption is that all cloud-native applications need to be integrated, which is much easier to accomplish if they all come with some form of messaging capability baked in. Integrating and managing federated instances of messaging systems still will be required. But much of the lower-level functions now being centrally processed will be pushed out into the applications being integrated.

    Collison is the first to admit that messaging is not some new, emerging technology. But as microservices architectures continue, messaging will prove to be core to a new generation of cloud-native applications, he said. The CNCF is clearly betting that a consortium of vendors working on a common code base for messaging will accomplish that goal a whole lot sooner.

    — Mike Vizard