devopsy.kinsta.cloud

Tag: microservices

  • 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

  • Service Mesh: The Best Way to Scale Enterprise Apps

    Service Mesh: The Best Way to Scale Enterprise Apps

    Microservices are great for DevOps, but the service-to-service communication these architectures depend on are complex to run and manage at production scale. Enter service mesh: the best way for enterprises to scale, secure and monitor apps. A service mesh is a dedicated infrastructure layer enabling service-to-service communication to be quick, secure and reliable. If you’re building cloud-native applications, you need a service mesh.

    After talking to development and operations teams it became clear that microservices are great for development velocity, but the complexity and risk in these architectures lies in the service-to-service communication that microservices depend on. Service mesh is an application-first approach to provide a communication fabric for microservices, giving DevOps teams the flexibility and autonomy they desire while providing the policy, visibility and insights into their microservice environment that operations teams demand for production-grade applications.

    A service mesh provides a robust microservice communication fabric to enable the best possible path to scaling containerized apps whether in the data center or in the cloud (or both). There has also been a recent emergence of enterprise-grade meshes to address the needs and complexity of enterprise production environments. A service mesh needs to do more than just scale apps; it also needs to monitor and secure them. A supported infrastructure allows DevOps teams the flexibility and autonomy they desire while providing the policy, visibility and insights into microservices that operations teams demand for production-grade applications.

    Advantages of a Service Mesh

    Think about your plans for microservices. Maybe you plan to have 10, 50, 100 or 1000’s of services running in your Kubernetes cluster. How do you get all of those services in your new microservice and container environments in an efficient, uniform way?

    Do you know who is talking to whom and if they are allowed to? Is that communication secure? How do you debug something when it goes down? How do you add tracing or logging without touching all of your applications? Do you know what the performance or quality impacts of releasing a new version of one of those services is on the upstream and downstream services?

    A service mesh helps answer those questions. As a transparent infrastructure layer that is inserted between your microservice and the network, it gives you a single point in the communication path of your applications to insert services and gather telemetry. You can do this without requiring changes to your applications.

    2018: The Year of the Service Mesh

    The concept of service mesh is relatively new. In fact, until 2018 was declared “The Year of the Service Mesh” at KubeCon in December 2017, most people had never heard of a service mesh. There are now several open source offerings such as Istio, and several companies building out supported meshes to take the burden out of managing microservices. It will be interesting to see how a service mesh enables organizations to further capitalize on containers and microservices.

    — Zach Jory

  • Top 3 Challenges of Adopting Microservices as Part of Your Cloud Migration

    Top 3 Challenges of Adopting Microservices as Part of Your Cloud Migration

    Many organizations embark on cloud migrations to achieve scalability, cost-efficiency and higher application performance. IDC estimates 60 percent of worldwide enterprises are migrating existing applications to the cloud. With the promise of greater flexibility, a reduction in overhead and the potential for significant cost savings, it’s a logical decision. But instead of performing a “lift and shift”—simply moving an existing application to a cloud platform—many businesses use the migration period as an opportunity to modernize the architecture of their applications.

    What’s more, in a survey by NGINX, over 70 percent of organizations say they’re adopting or exploring microservices for their new architectures—and with good reason. A complex name for what is relatively a simple concept, microservices refers to a concept whereby individual parts of an application are constructed as discrete, modular building blocks. Breaking a monolithic application into manageable microservices allows development teams to rapidly respond to an ever-evolving set of business requirements, choose the right technology stack for each task, and readily provide support for a variety of delivery platforms, including web, mobile, and native apps.

    But with the great benefits that microservices bring, there are also some challenges that enterprises face as they look to adopt new concepts to maintain their competitive edge. In fact, adopting microservices as part of your cloud migration isn’t always easy. Below are three common challenges we’ve seen enterprises face, and solutions to help mitigate these risks.

    Challenge 1: Identifying What Needs to be Migrated to Microservices

    Before you can begin breaking your application out into individual microservices, you first need to understand its full scope and architecture. This can prove challenging, as many times the overarching view of the application is based on “tribal knowledge” or cobbled together from a collection of disparate tools. Sometimes a more holistic view may be available, but is based on outdated information that does not reflect the current architecture of the application.

    Related Content:

    DevOps in the Cloud: Security’s Groundhog Day

    The Challenges of Digital Experience Monitoring

    You need to find a solution that will help you discover and map every component, dependency and third party call of your application. This solution should help you understand the relationship of these pieces and how each impacts your application’s behavior and user experience. Armed with this information, you’ll have a clear picture of what needs to be migrated and will be able to make more-informed decisions regarding the architecture of your microservices.

    Challenge 2: Ensuring Your Microservices Meet or Beat Pre-Migration Performance

    To ensure your application runs smoothly post-migration, and that user experience was not negatively impacted, you need a way to compare performance metrics from pre- and post-migration. This can be extremely difficult, as the architecture of these two environments (with the changes to hardware and the move to a distributed architecture) can look drastically different. To make things even more difficult, the monitoring tools supplied by individual hosting providers give insight into only a small portion of the entire architecture and have no way of creating a more holistic set of data.

    To combat these issues and establish a consistent baseline by which to measure your performance and user experience, you will need to capture key user interactions (often referred to as business transactions), prior to beginning your migration. The business transactions are likely to remain the same through migration whereas other metrics may change as you take different code paths and deploy on different infrastructures. Armed with baseline data about your business transactions, you can easily compare the performance of your pre- and post-migration environments and ensure that there is no impact to your user experience or overall performance.

    Challenge 3: Monitoring Your New Microservices Environment

    With large, monolithic applications running a single codebase on a few pieces of hardware, two or three tools could once provide complete, straightforward monitoring of application and infrastructure performance. However, with the introduction of microservices and the potential for each service to implement its own solution for technology stack, database and hosting provider, a single service may now require a greater number of monitoring tools than the entire application once did. And microservice monitoring brings specific challenges: They are often short-lived, which means monitoring over a longer period of time can be more complicated, and there may be more pathways through which the service is reached, potentially exposing issues such as thread contention.

    Finally, while development teams previously didn’t require a monitoring solution that took infrastructure into account, the move to DevOps and the reliance on cloud-native technologies means this factor can no longer be ignored.

    Changes in consumer behavior and expectations have been the catalysts for large tech trends including cloud computing and mobile device adoption. While the change of pace can be dizzying for many, as the need for speed in application development is greater than ever before, cloud migration is possible. The goal for any business looking to successfully adopt microservices as a part of its cloud migration is to find a unified monitoring platform that supports all of your environments, regardless of language or technology stack. This solution must collate metrics from across your application and infrastructure into a single source of truth and allow for correlation of those metrics to user experience.

    — Matt Chotin

  • The Executive’s Guide to Microservices Chapter 3: Choosing A Starting Point

    The Executive’s Guide to Microservices Chapter 3: Choosing A Starting Point

    In the previous chapter, Steve had been asked to provide a comparison of costs and resources needed to migrate to a commercial system versus modernize the current system. He works with Stacey, head of development, who comes up with a modernization plan that includes certain changes that the team will implement to limit downtime.

    Steve has discussed Stacey’s plan with the business, which agreed with the approach toward modernization of the supply-chain system. The business particularly likes the idea that in the future the reduced fragility of the system might mean its IT teams can introduce ongoing improvements even through the holiday season, rather than having to freeze all systems development for a period of four months.

    Now Steve and team are challenged with where to start.

    The team has decided that any changes will require decomposition of the existing monolithic design. The approach to date had been to address requirements functionally, which meant that every time the business requested changes to the system, the code was changed to support those requirements by adding specialized logic to various modules.

    Unfortunately, this approach has resulted in significant amount of technical debt. Each compounded change introduced conditional logic to support prior requirements. Moreover, each new change had the potential to break prior changes, so time-consuming impact analyses had to be done before any changes could be made.

    Steve and team want to decompose the system into a set of microservices that closely resemble the business function they support. Moreover, they want to segregate the specialized business logic into modules that consume the generic business services.

    Obviously, this is a long-term strategy, so Steve and team need to choose how to approach incrementally to enable them to make major strides before this year’s systems freeze. Given the proximity to the holiday buying season and the availability of resources, Steve and team will need to choose wisely which microservices they will create. Moreover, Steve and team know they will be limited by the level of entanglement within the existing code.

    After an initial analysis Stacey’s team determines that the costliest issues stem from the logic to support multichannel customer engagement. That part of the system integrates custom logic with some off-the-shelf ecommerce products. During the holiday season, customer support calls increase in volume and each call can last five to 50 minutes. The large variation is often caused by the inability of the system to address changes in a particular channel post order-placement. For example, if the customer wants to add a gift receipt or wrapping after the order is placed, it must be dealt with out of band. This means that the business has had to add support people during the holiday season just to deal with these issues.

    Stacey and team also believe they can easily isolate the logic for multichannel support within the existing code base and decompose into a set of microservices. The team decide that the existing customer records system must stay as is for the time being, but they can create a new API to more easily access that data from the new microservices. Stacey calls these macroservices.

    The team will create a set of microservices to support the web channel and a set to support the distributor channel, since these each have very different requirements. The current system combines the logic to support both of these in one module today. Since microservices are supposed to be focused on doing one thing well, the team have decided on the following bounded contexts: order creation, order execution (payment), order fulfillment and returns.

    Steve asks Stacey, “Why not just have an order service?”

    Stacey replies, “That is one approach, but we would call that a miniservice as it manages all aspects of orders. However, our goal is to allow parts of the system to change over time with minimal testing and maintenance required. A microservice change should not have broad system implications. Changing the order miniservice could mean that an entire channel could be impacted. With this approach we could change any of these supporting order processes without impacting the entire order function within the company.”

    Steve thanks Stacey for her answer and tells her he has a much better understanding now for what the team is trying to achieve.

    — JP Morgenthal

  • Subtree Rises to Microservices Data Management Challenge

    Subtree Rises to Microservices Data Management Challenge

    Fresh off raising $10 million in funding, Subtree has emerged from stealth to launch a service based on the dotmesh open source utility for microservices to enable DevOps teams to capture the entire state of applications.

    Dotmesh captures application state as a series of units known as datadots, and captures and tracks all versions of all the databases, files and other data in any application based on a microservices architecture, said Subtree CEO Luke Marsden. That utility exposes a command line interface (CLI) through which data about the application captured by dotmesh can be collected, and a dotmesh server component stores all the datadots.

    Marsden said the dotmesh utility can be applied to any microservice regardless of what runtime or class of containers is being employed.

    Once captured, that information can be shared via a dothub repository managed as a service by Subtree. Marsden said there’s no requirement to use dothub as the repository because the dotmesh utility is available as open source code. But dothub is designed to be the most efficient way to share data about the state of microservices applications distributed across the enterprise, said Marsden.

    The goal, he said, is to provide the equivalent of the service for source code that Github makes available and designed specifically for sharing information about the state of microservices applications deployed in production environments.

    Related Content:

    Red Hat Survey Sees Broad Adoption of Microservices

    Flexera Extends Scope of Open Source Scanning Tools

    In effect, the combination of dotmesh and dothub creates a new type of service mesh for tracking and managing data, Marsden said.

    He noted that microservices create a significant data management challenge because best practices call for each one to have access to its own database. Managing applications made up of microservices that are tethered to larger numbers of databases makes it difficult to ascertain the state of an application built on top of multiple microservices, Marsden said. If one microservice should fail, for example, the DevOps team often has to stop the application because of all the dependencies between them. However, dotmesh utilities tethered to the dothub service via application programming interfaces (APIs) make it easier to determine the relationship between all those microservices and their data sources, he said.

    Subtree envisions DevOps teams employing both dotmesh and dothub together to create workflows that specifically address data management in a microservice environment. The degree to which IT organizations are currently challenged by data management varies according to the number of microservices they are attempting to manage. At some point, however, just about every IT organization that embraces microservices will need to address how the data attached to each microservice gets managed, especially within the context of a larger stateful application.

    The impact of a lack of data management that is designed for microservices is already being felt. Many organizations are unable to effectively test a microservices-based application because the tests don’t accurately reflect the true size and scope of the application.

    Pricing for the dothub service is $10 per month for 5GB of storage. There’s also a free tier of storage provided for up to 1GB of storage.

    It’s still not quite clear who inside IT organizations will manage the data being accessed by what inevitably will become thousands of microservices. But it is clear that currently, the tools for managing all that data are, for the most part, nonexistent.

    — Mike Vizard

  • 7 Principles for Using Microservices to Build an API That Lasts

    7 Principles for Using Microservices to Build an API That Lasts

     

    SparkPost launched the first beta version of our cloud-based email delivery service three years ago. At its introduction, a handful of customers sent a few million emails a month. Now, our API is used by tens of thousands of customers—including Pinterest, Zillow, and Intercom—to send more than 15 billion emails a month. That dramatic growth demonstrates how rapidly our business pivoted from providing on-premises email infrastructure to operating as a fully cloud-based email delivery service.

    It’s a great business story. But how did we manage change at that scale with regard to technology and development management? In this article, I’ll review several of the choices and best practices that have helped us to not simply manage this pace of change, but actually to thrive from it.

    REST Is Best: Be Practical, Not Pedantic

    From the start, we took an “API first” approach. Our email API is our core application, not an afterthought.

    The first, and most important, step we took was deciding to use REST for our API. Our philosophy was to choose the following three elements as our API’s foundation:

    1. HTTP: This covers response codes as well as operators. The operators include POST, GET, PUT and DELETE, and they can be mapped to the basic CRUD (create, read, update, delete) operations.
    2. Resources: These are the entities that the HTTP operators act on.
    3. JSON (JavaScript Object Notation): This is a data-interchange format.

    Those three elements provide everything needed for a practical REST API, including simplicity, portability, interoperability and modifiability. After the API is built, users can easily integrate against it regardless of their programming language, including C#, PHP, Node.js, Java or even cURL in a shell. They can do so without worrying about the underlying technology, including its use of multiple microservices.

    When we created the SparkPost API, we tried not to be too pedantic about following a pure REST model, opting for ease of use instead. Here are two examples that may not follow RESTful best practices:

    1. GET /api/v1/account?include=usage
    2. POST/api/v1/sending-domains/example.domain.com/verify

    The first example uses a query string parameters for GET to filter what comes back in an entity. In the second example, we use the action word “verify” in the endpoint name, which may not be RESTful. We discuss each new use case and do our best to ensure it’s consistent and easy to use.

    Related Content:

    APIs: Automation is Great. So is Usability

    Tips to Optimize the Cloud for Scaling

    Evolving and Managing Change

    We have many developers and teams working on our API’s microservices, with changes delivered on a continuous basis. We automate deployment of a change to production when an engineer (and a second) concludes it has passed our tests. It’s “released” when the product team decides we’re ready to tell customers about the change.

    We decided early on to keep our API consistent in its use of conventions and how changes are managed. We established a governance group that includes engineers representing each team, a member of the product management group, and our CTO. This group establishes and enforces our API conventions, which are thoroughly documented.

    Documenting our conventions reduces inconsistencies and makes it easier to define each new endpoint. Here are a few conventions we’ve established:

    • URL paths are lowercase with hyphens when separating words, and are case sensitive.
    • URL query parameters and JSON fields are also lowercase with underscores, and are case sensitive.
    • Unexpected query parameters and JSON fields in the request body should be ignored.

    Our governance group also sets the ground rules for how changes can be made and what types of changes are allowed. There are a number of good API changes that are beneficial to users and don’t break their integrations, including:

    • A new API resource, endpoint, or operation on an existing resource
    • A new optional parameter or JSON key
    • A new key returned in the JSON response body

    Conversely, a breaking change includes anything that could break a user’s integration, such as:

    • Changing a field’s data type
    • A new required parameter or JSON Key
    • Removal of an existing endpoint or request method
    • A materially different behavior of an existing resource method, such as changing the default for an option from “false” to “true”

    Those kinds of changes will either break users’ integrations or require the addition of a new version, which introduces more overhead.

    Don’t Break Bad When Making Changes – Nearly All the Time

    Breaking changes should be avoided, even if they’re the result of fixing bugs or inconsistencies. It’s usually better to work around such idiosyncrasies rather than risk breaking customers’ integrations. If a change is of the breaking variety, we proceed with extreme caution and seek out alternative ways to achieve our goal. Sometimes that can be accomplished by simply allowing the user to change their behavior through an account setting or an API parameter.

    However, there are times when the benefits to our users outweigh any potential negatives that would be introduced by a change. In those cases, though, we followed these best practices:

    • We received buy-in from our product, support and developer relations teams.
    • We analyzed API logs to see how many users the change might affect.
    • We gave users at least 30 to 60 days of advance warning about the change.
    • We sent an email or published a blog post containing explicit details of the change and why we were making it.
    • We provided guidance in the API documentation.

    One Version to Rule Them All

    After making thousands of changes to our API during the past three years, we’re still on the first version. We decided early on not to version our API beyond the first one because doing so adds a level of unnecessary complexity that can slow down user adoption of our latest and greatest functionality. Versioning an API can also slow down development and testing, complicate monitoring and confuse user documentation.

    In addition, not versioning our API means we can avoid the controversy that tends to swirl around the subject. There are three ways to version an API, and all of them come with potential pitfalls:

    • Put the version in the URL: Easy to do but a bad choice from a semantic perspective because the entity doesn’t change between v1 and v2.
    • Add a custom header: Also easy to do but not semantically correct.
    • Put the version in the accept header: More semantically correct but the most complicated approach.

    Use Client Libraries to Help Non-JavaScript Users

    Some of our users prefer Python, C#, Java or PHP over JavaScript. We make it quick and easy for them to integrate our API into their applications by maintaining client libraries that offer an easy-to-use set of functions for their code.

    Our client libraries have changed over time, and we do version them. We’ve learned that abstraction is hard when wrapping a living, growing API, so we focus on providing a thin layer of abstraction with some syntactic shortcuts that simplify the more complex areas of our API. Doing so lets our users quickly hit any of our API endpoints quickly and with a lot of flexibility—it also lets us “future proof” our API to some extent.

    A ‘Documentation First’ Strategy, Too

    We treat our documentation as code and use it to document our API changes before we write or change a single line of API code. Doing so helps us enforce our conventions, keeps everything consistent and maintains a good customer experience. It also cuts down on support costs.

    We maintain our documentation in GitHub, which makes it easy for technical and non-technical users to contribute changes. We’ve also found that it’s easier to review changes that way. We use API Blueprint Markdown format and Jekyll to generate the HTML docs, along with a nice search service called Algolia. Doing so lets us have full control over the customer experience, including mobile.

    For those who don’t want to “roll their own” documentation, we recommend OpenAPI (previously known as Swagger), Apiary and API Blueprint. It’s important to avoid a tool that isn’t well-suited for REST API documentation. We suggest including a bright orange “Run in Postman” button in the documentation so it’s easy to try an API, along with good examples of success and failure scenarios.

    Listen to Users

    Finally, we recommend that all developers pay attention to what their users have to say. SparkPost has a community Slack channel where thousands of users can easily access members of our product, support, engineering and executive management teams. We also have a dedicated Developer Relations team that’s squarely focused on engaging with the developer community. All of that allows us to listen to our users and incorporate their feedback into our API.

    — Chris McFadden

  • Red Hat Survey Sees Broad Adoption of Microservices

    Red Hat Survey Sees Broad Adoption of Microservices

    A new survey from Red Hat shows the extent to which IT organizations are moving to modernize their IT environments: More than two-thirds of respondents (69 percent) reported they are using microservices for both new applications and re-architecting existing ones.

    The survey, which includes responses from 168 IT professionals employing either Red Hat JBoss middleware or Red Hat OpenShift platform-as-a-service (PaaS) software, also confirms that IT organizations are employing a mix of legacy and emerging programming models to build and deploy microservices, says Rich Sharples, director of product management on the middleware team at Red Hat.

    Related content: DevOps Chat: Microservices & Containers – Mastering the Replatforming of the IT Infrastructure

    For example, Sharples notes, many of the microservices being deployed inside the same organization are being built with both traditional Java programming tools as well as so-called new stacks of software based on containers such as Docker. In fact, a full 87 percent of the respondents are either using or considering multiple technologies to build and deploy microservices, and nearly half the respondents (45 percent) said their organization is committed to “using the right tool for the right task” versus forcing the organization to employ a single technology, runtime or framework.

    The top five benefits attributed to microservices are continuous integration/continuous deployment (CI/CD), agility, improved scalability, faster time-to-market, higher developer productivity and easier debugging and maintenance. One-third of respondents (33 percent) said they have achieved two of goals by implementing microservices in the last two to six months.

    However, making the shift is by no means easy. The top four challenges associated with making the transition cited by respondents are developing/implementing in-house microservices tooling, reorganizing their organizations, working with vendor subject matter experts/using a vendor as a trusted advisor and purchasing or using a platform/solution.

    Microservices clearly are not for the faint of IT heart. Developing and managing a handful is relatively trivial. But managing them at scale can prove daunting to even the most skilled IT organization. Sharples says the most important decision an IT organization can make is determining what application workloads to deploy as a microservice. In many cases, IT organizations will be better off rewriting an existing application that they know how to run than trying to create an application from scratch employing microservices—not only to gain experience, but also to be able to compare the results achieved against what was previously delivered as a monolithic application, he says.

    In many ways microservices are the next logical extension of concepts that were pioneered with the advent of service-oriented architectures (SOA) more than two decades ago. The difference now is that microservices tend to be more granular and are often maintained by the developer rather than a centralized IT operations team. Regardless of what level of appreciation an IT organization may have for the history of computer science, the one thing that is clear is microservices are being more broadly adopted than advocates of SOA ever hoped to imagine.

    — Mike Vizard

  • The Executive’s Guide to Microservices Chapter 2: The Business Challenge

    The Executive’s Guide to Microservices Chapter 2: The Business Challenge

    Steve and team have been working diligently to analyze the intricate web of code that has been organically developed over the past 12 years to design a program to modernize the application. Application is actually a poor name for all that Steve and his team manages. Steve’s team manages a complex custom supply-chain system that manages inventory, warehouse, picking, packing, shipping and order management. A hiccup in any module could lead to a serious financial impact to the business.

    The business has discussed multiple times over the years switching to a commercial product, such as Manhattan or SAP, but the costs and challenges of doing so without interruption to the business resulted in a decision to keep maintaining the current system. The business has been judicious in its requests to update the system, understanding that changes take a long time to implement and test due to the design. However, competition from major online retailers are starting to seriously impact profitability, forcing the business to make a considerable investment.

    The supply-chain system is comprised of multiple modules mostly written in the Java programming language, but some of the older modules are in C++ and require a Windows Server operating system. This combination of technology has been a source of strife for Steve’s team. They have tried multiple technologies over the years to make the system more stable and to isolate the older C++ modules in a way that reduces risk of downtime should they crash. The Java modules were written to run inside of a web application server, which provides some linear scalability, but it’s still an issue to scale the C++ modules in a relative manner. Now, increased demands from the online channel is stressing the system in ways that it was never designed to handle.

    The business has asked Steve to provide a comparison of costs and resources needed to migrate to a commercial system versus modernize the current system. However, there is one constraint that is limiting the business moving to a commercial version at this time: There are five months until the winter shopping season freeze, when all changes must be completed with no further changes to the systems until February of the following year. Most of the time estimates from integrators for the commercial version are more than 12 months in duration.

    Steve’s company is really between a rock and hard place. If it doesn’t fix the system Steve is managing, it may not be able to scale to the volumes the company needs to be profitable this holiday season, but the company has waited so long to decide to move to a commercial package that it won’t be ready in time for the holiday buying season regardless.

    Likewise, Steve and team are in a similar difficult position. Their efforts around a modernization program have yielded some potential wins that could allow the business to achieve many of their desired outcomes before the winter shopping system freeze. However, there is a culture of fear that permeates Steve’s team. Whenever this system has failed in the past, there were significant reprisals from the business in the form of multi-day “all hands on deck” sessions, where the entire team was expected to be there from 7 a.m. until 8 p.m. until the system was operational again, not to mention letting go those who introduced bugs into production releases.

    Stacey is Steve’s head of development. She brings the modernization plan to Steve for review, but makes it clear that the team believes there are some potentially high risks associated with the approach. While the Stacey and team believe they will be successful, they want assurances from the business that they have the leeway and support to take the risks without reprisal. In return, Stacey tells Steve that there ares certain changes that the team will implement to limit downtime if something should occur:

    1. They will adopt a strategy that developers are responsible for fixing anything they break.
    2. They will be implementing a new continuous integration and deployment tooling that will automate the integration build, unit testing and review of any code changes speeding release of updates and fixes into production.
    3. They will be adopting the Agile Scrum software development life cycle to deliver functional changes every two to three weeks.
    4. They will set up a Kanban board online that will allow the business to track and understand where the proposed capabilities are and when they will be completed.
    5. Before each sprint the business will have a chance to reprioritize any features or capabilities so as to ensure that the most important features get completed prior to the system freeze.

    Steve likes Stacey’s plan and agrees to take it to the business. He explains to Stacey that there will be a natural tendency to push back, but given the urgency and lack of options, this may very well be the best time to push for these changes in their company. In the past, there has not been a lot of tolerance where IT systems impacted financial performance. It’s now Steve’s job to help the business understand that, with the growing dependency on software in business, its expectations need to change for the business to successfully compete.

    — JP Morgenthal

  • DevOps Chat: Microservices & Containers – Mastering the Replatforming of the IT Infrastructure

    DevOps Chat: Microservices & Containers – Mastering the Replatforming of the IT Infrastructure

    The replatforming of the enterprise IT infrastructure utilizing microservices and containers is no small undertaking and is usually provoked by a shifting set of key business drivers. That is precisely the case today. The term “digital transformation” is in the hearts and minds and on the lips of top-level business executives and IT leaders alike. The underlying traditional or legacy infrastructures that have dominated enterprise IT for nearly 30 years simply cannot handle the workloads or power the applications that will drive business decisively forward.

    Microservices & Containers

    Both microservices and containers are destined to play a major role in this enterprise replatforming, for different reasons. Containers, for their part, hold significant benefits both for developers and the development effort as well as for the organization itself. Understanding this range of benefits is instrumental to securing IT budget for containers going forward.

    In this DevOps Chat, Jim Scott, director, enterprise strategy and architecture at MapR, discusses the most promising and compelling tools, technologies and solutions destined to play a major role in this replatforming of the enterprise. Jim highlights how to stay one clear step ahead as IT undertakes what is arguably its most mission-critical task in a generation.

    You can also download a great ebook on this topic by Jim at here.

    As usual, the streaming audio of our chat is immediately below, with the transcript of our conversation below that.

    Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 118809″ target=”blank” width=”300″ height=”300″]Jim Scott
    Jim Scott is Enterprise Strategy & Architecture at MapR Technologies and is very active in the Hadoop community. Jim helped build the Hadoop community in Chicago as cofounder of the Chicago Hadoop Users Group. He has implemented Hadoop at three different companies, supporting a variety of enterprise use cases from managing Points of Interest for mapping applications, to Online Transactional Processing in advertising, as well as full data center monitoring and general data processing. Jim also was the SVP of Information Technology and Operations at SPINS, the leading provider of retail consumer insights, analytics reporting and consulting services for the Natural and Organic Products industry. Additionally, Jim served as Lead Engineer/Architect for Conversant (formerly Dotomi), one of the world’s largest and most diversified digital marketing companies, and also held software architect positions at several companies including Aircell, NAVTEQ, and Dow Chemical. Jim speaks at many industry events around the world on big data technologies and enterprise architecture. When he’s not solving business problems with technology, Jim enjoys cooking, watching-and-quoting movies and spending time with his wife and kids. Jim is on Twitter as @kingmesal.[/su_pullquote]

    Alan Shimel: Hey everyone, this is Alan Shimel devopsy.kinsta.cloud, and we’re here for another DevOps chat. We’ve got a nice chat lined up today. Lucky enough to be joined by Jim Scott of MapR. Jim, welcome to DevOps Chat.

    Jim Scott: Thanks, Alan.

    Shimel: Thanks for having – thanks for being with us today, Jim. So Jim – well, let’s start with this. Our audience may or may not be familiar with MapR, but let’s assume for the moment they’re not. Can you give us a little bit of background about MapR?

    Scott: Sure. So MapR is a converged data platform. The operable words being “data platform.” So MapR provides a data platform for all data. All types of data, all locations, cloud on premise, and it can run in all of those locations simultaneously. The premise of the platform is to deliver a standard open API architecture on top of our data platform, so that customers can reap the benefits of our platform, but not have to worry about being locked in to the vendor, MapR, for the software that we provide through those open APIs, or even the infrastructure that you choose to run on.

    So if you wanna run on your hardware in your own data center, or if you wanna run your software in the cloud or multiple clouds, you can run your software on top of MapR on any of that infrastructure, anywhere you choose, any time.

    Shimel: Great. So Jim – and just for our audience information, what’s your role with MapR?

    Scott: Oh, so for MapR I’m in charge of enterprise architecture, both internally and externally.

    Shimel: Excellent.

    Scott: So what that means is internally, I’m basically lining up and showing how we’re using MapR to solve our own problems, and then externally, it basically means I work with our customers a pretty substantial amount, helping them work through how to be successful with a big data platform. So what is the right way to do something. I’ve personally worked in a large number of different industries, and so my experience comes to the table quite often.

    Shimel: Got it, got it, got it. We got a little vibration there, but I think it went away. And Jim, as we were talking off-mic before we started today, I was telling you I had covered MapR back in Network World when you guys launched, and I’m gonna guess that was around 2008 or so. Correct? 2009, maybe?

    Scott: Yeah, the company went in – or was founded in stealth mode in 2009.

    Shimel: Yep, I remember it. So certainly there’s been a lot of water under the bridge in terms of in 2009, cloud itself was quite the rage. It was relatively new, still, and people were still figuring that out. The whole big data market – there wasn’t a market for big data, frankly. Hadoop and these things had just come out.

    But Jim, probably one of the biggest innovations or changes in infrastructure over the last two or three years, maybe four, has been the big move to containerization of microservices. I would imagine you’re seeing this at MapR as well.

    Scott: Yeah, absolutely. So if we look historically, just say maybe eight, ten years back, message-driven architecture started becoming popular; service-oriented architecture, things of that nature. And that popularity was great – eh, maybe even 15 years back. But the problem was scaling out the messaging platform itself was difficult, it was expensive, and it was really just a pain from an administration perspective, to be able to scale out.

    So we’ve seen this transition over the last handful of years, moving more towards a microservices model. And the term – a lot of people like to throw it around loosely and call something a microservice when it’s not, but the less monolithic in nature, the more difficult to handle the large scale.

    Which is why the Kafka API and what MapR provides with MapR Streams helps enable the customers, because they have the ability to push through massive volumes at a linearly scaling cost model, so they know exactly where they’re going. So it’s pretty easy to push through something like 1.5 trillion events per day on a platform like MapR with as little as five servers.

    And the more micro in nature, the higher the volume you’re going to need to be able to handle. And so those messaging systems of the past – just not there. Just couldn’t handle it. I mean, I remember being excited when we were getting 50,000 to 60,000 messages per second through the system.

    Shimel: For good reason, Jim. You’re talking to someone who was excited when the 386 came out. So yeah, I hear you. But Jim, fundamentally what my – and I just had this discussion, because we actually have a little microservices journal, Microservices Neighborhood, within devopsy.kinsta.cloud. And I was talking to JP Morgenthal, who’s a CTO at DXE, actually, about this just yesterday.

    Fundamentally, fundamentally – and we’re talking about real microservices now, not nonsense, right? But fundamentally, it has such promise to change the way we do development and to change the way our infrastructure runs, right? Especially when you marry it to containers.

    Scott: Yep. Yeah, and I think what you’re alluding to, and this is one of the things that I have the biggest problem with when talking with people about microservices, is the fundamentals are that a microservice is really more about the deployment model than anything else.

    And without a container to be able to put it in and deploy it, it becomes a very difficult and unwieldy thing, even though it’s so small.

    Shimel: Got it. So Jim, you mentioned before you were working on both the internal and external aspects of this. Internally, if you can – let’s not give away any company secrets – but internally, is MapR utilizing your container-based infrastructure with microservices?

    Scott: Uh-huh, absolutely. Yeah, matter of fact, we talk about it pretty regularly. So for our own website, we have implemented customer 360 capabilities. We run our software inside of containers, and we run it currently on one cloud, but we have on-premise hardware, and we will be in the not-too-distant future running multicloud and on-premise all simultaneously. And in order to do that you need a technology like a container to get that type of isolation from your infrastructure.

    Shimel: Yep. An abstract, if you will; an abstraction – I had an interesting conversation, Jim, with I think it was at _____ recently, or another site, another large organization who had totally moved to a containerized infrastructure, and he was talking about what a profound change it was.

    And I asked him about patching containers versus immutable infrastructure, just standing up new ones, replacing the old, rather than actually patching the existing ones. Where are you on that question, if you don’t –

    Scott: Well, I love the concept of being able to go back to my base, default image and be able to run it through my entire devops process, continuous integration process. So I can go patch one instance in my dockerfile, I can test the core out, make sure it’s doing what it’s supposed to, and then I can let all of my downstream builds run, pick up the new container, and run them through their integration tests.

    Shimel: Excellent. So Jim, I don’t know if everyone in our audience understands this whole idea of eating your own dog food, and what it means. But can you maybe give us an example or two of how things you’ve learned by using them internally at MapR have translated into better service, better product, better results for end users?

    So how you’ve taken it out, how you’ve taken certain processes or waves of technology that you use yourself, and translated that into a customer experience.

    Scott: Yeah, so there’s a couple that pop to mind, and number one is actually containers. We only introduced support for containers around the beginning of this year.

    Shimel: Really?

    Scott: But we’ve been using – yeah, it was – I think our press release that we did on it when we officially released support was around February time frame this year. But technically speaking, we have a number of customers who’ve been using containers with MapR for two, three years.

    And little secret here: We use it internally, and have been for two, three years as well. So making sure that we had it fully vetted and very well baked from a support infrastructure perspective was really critical, but getting that out there for customers, really important.

    Because it solves such a major problem with containers, which is you look at something so simple as security, right. If I am responsible for the web server for my company and you are responsible for the financial systems of your company, or of my – or our company, that software in a container has the ability to run on the same server.

    But if they run on the same server and we are utilizing local storage on that server – because you can’t save data inside a container; it blows up. It’s gone when the container dies. So if you save data locally on that server, what happens? Well, suddenly I run these security risks of my web server having access to financial information – probably not a good idea.

    Shimel: No.

    Scott: So we implemented, within our MapR persistent application client container, the ability to talk to MapR from within the docker container. And because MapR offers NFS support, it’s almost invisible and there’s hardly anything to do. And you give it a ticket from your authentication environment, and you’re good to go.

    Whatever’s running inside that container has a user ID, and when it talks to MapR, the data is saved and protected. You don’t have to worry about oh, well, if I’m gonna save data, I’ll save it to the local server. You get rid of that whole problem. It isolates where the data goes, already being protected and highly available, if your server physically dies, just like if your container dies, you don’t care. You don’t have to restore the server to try and get the data off of it.

    Shimel: Got it, got it. That’s 100 percent – that’s the beauty of that whole abstraction layer, if you will.

    Scott: Exactly.

    Shimel: Jim, here’s an interesting question, and I don’t know if you have this info, but I figured I’d ask anyway. We’ve been doing a bunch of surveys about container adoption, and it’s funny, we’ve done several of these surveys now over, let’s say, the last two years, and when we first started, a lot of people had plans of looking at docker and containers.

    Other people, a decent amount of people, had containers in their – they were in the testing dev environment kind of thing, not production. Few had them in production. Then recently, like our most recent surveys, let’s say, over the summer, that number shot up. Probably 40, 50 percent of respondents have containers in production.

    That may be because it’s devopsy.kinsta.cloud, we’re in a devops bubble, and so you get people using this kind of new stuff. But I’m curious, out of the MapR customer base, a gut check if you don’t have the real number, what do you think the percentages are that are using containers in production these days?

    Scott: It’s a pretty big number. I don’t have a hard-and-fast number, but if I just go by the customers that I talk with, I feel like it’s gotta be over 50 percent.

    Shimel: Really? Wow.

    Scott: Yeah. Yeah, we’ve got one extremely advanced customer in Australia, their name is Quantium. And they talk about how they use MapR all the time, and they’ve basically reinvented their entire operating model, and they’ve done it on top of MapR. There’s an enterprise architecture I documented that they talk about periodically; it’s called the zeta architecture.

    They basically use an orchestration layer, they use MapR for persistence, and then they use containers to launch and deploy anything anywhere arbitrarily across their cluster of hardware for their customers. And they turned their entire internal platform to an as-a-service model for internal and external customer consumption.

    Shimel: Got it, excellent, excellent. We’re hearing stories like this all over now, and the interesting thing is it’s almost wherever you see containers, you’re seeing microservices. But you’re also seeing microservices in places where you don’t necessarily also see containers.

    And it reminds me of when I was in school, we used to learn all pasta is macaroni, but not all macaroni is pasta, or something to that effect. But microservices has a place outside of containers, though they seem to just go really well together.

    Scott: Yeah, absolutely, and I think when you start looking at the different types of use cases that you would fit into a microservice, this is where you start seeing how people are going to choose to deploy and manage. If you’re looking at event-driven, message-driven, where it’s taking a message in, it’s doing some work and it’s dropping a message back out, versus it’s a restful service endpoint, where it’s a synchronous response.

    Yeah, people are choosing to do things in different ways, but nearly – everyone that I talked to, they’re using containers in some fashion.

    Shimel: Yep, yep. It’s true in my case too, but like I said, I always figure well, I’m in a bubble, so of course I’m gonna see that. Jim, what’s next for MapR?

    Scott: Oh, that’s an in intriguing question. Recently, we announced our 6.0 launch, and we have greatly enhanced a number of features around our database capabilities. I seem to have this conversation a lot with people, is they start looking at big data technologies, and they say well, this is great and all, but I’ve built this software to work with mySQL or Postgresql or Oracle or whatever RDBMS.

    So that’s fine, you can containerize those applications if you wanna start changing your infrastructure and how you orchestrate your software, and if it’s important enough to you, you could migrate it over onto a no SQL database like MapRDB document database, or you can just leave it running in a container so you have a more flexible infrastructure.

    And the database technology enhancements that we’ve been making are really critical to kind of driving the future of getting people off of those super-expensive to scale RDBMSes that are being used for non-relational purposes.

    Shimel: Excellent. Just time frames – when might we see some more on this stuff?

    Scott: Well, it’s been announced in the last few weeks, and so we’ll start our 6.0 general availability very soon. I forget the exact date. Then we’ll just continue plugging along, adding more new, fantastic features to help enable the customer base.

    Cloud integration with our platform is another really big one, making sure that we can help enable customers to benefit from the concept of cloud neutrality. Cloud providers are never just gonna get together as a consortium and say hey, why don’t we standardize our APIs to the benefit of our customers?

    It just doesn’t happen. It’s not gonna happen. Google, Microsoft, and Amazon are never just gonna call each other up and say hey, what do you think about this?

    Shimel: I agree. Agreed. Well, not – you know what – well, I was just, I’ve seen a lot of changes over the years, but that’s probably a pretty safe bet, Jim.

    Scott: Yeah.

    Shimel: Unfortunately. Anyway, Jim, believe it or not, as I told you when we started, the time goes really quick, and we’re about out of time for this version of DevOps Chat. But we’d like to maybe have you back on in the future. We’d love to keep up with what’s happening with MapR, especially as it relates to microservices and containers and some of the new stuff we have going on.

    Jim Scott: Yeah, sounds great.

    Shimel: Great. But in the meantime, if people wanna get more information about MapR, where can they go?

    Scott: Well, I would recommend they go to MapR.com.

    Shimel: Okay.

    Scott: Or of course, you can always follow MapR on Twitter and/or any of the other social networks that you join and work with. But the website is always my favorite, because there’s a lot of great material there, including the MapR blog, and all of the ebooks, including the “Microservices and Containers” ebook that I wrote is out there, for free.

    Shimel: Got it. Got it, got it, got it. All righty, well, we’ll have to maybe get some links to those we’ll put in the show notes of this as well.

    Scott: Yeah, that’d be great.

    Shimel: Fantastic. Hey, Jim, thanks for being our guest on this episode of DevOps Chat. Look forward to having you back soon and finding out more about MapR. Continued success, and keep us posted about what you guys are doing.

    Scott: Thanks, Alan. Appreciate it.

    Shimel: All right. Hey, everyone, this is Alan Shimel for DevOps Chat on devopsy.kinsta.cloud. Thanks for joining us, and we’ll see you soon on another chat. Take care, everyone. Bye-bye.

    — Alan Shimel

  • LightStep Unveils APM for Microservices

    LightStep Unveils APM for Microservices

    Various forms of application performance management (APM) platforms have been around for some time. But with the rise of microservices many IT organizations are discovering that legacy APM platforms were not designed to handle the volume of software modules or the rate at which those modules are updated. But LightStep, a startup founded by former Google employees and flush with an additional $29 million in funding, is positioning itself as the first APM written from the ground up for microservices environments.

    LightStep CEO Ben Sigelman says regardless of where software modules and components get deployed, LightStep [x]PM is capable of monitoring and troubleshooting performance issues across all web and mobile clients, monoliths and microservices.

    Most of the demand for LightStep [x]PM, he says, is being driven primarily by microservices based on containers such as Docker. But the APM platform itself can support both microservices and legacy monolithic applications. That creates an opportunity to rationalize APM platforms as organizations make the shift to microservices while continuing to need to support existing legacy applications running in a production environment, Sigelman says.

    Twilio, Lyft, Yext, GitHub and DigitalOcean are already using LightStep [x]PM, which traces its roots back to Dapper, an always-on distributed tracing system that Sigelman developed at Google in production environments. A decentralized architecture enables LightStep [x]PM to continuously analyze 100 percent of transactions across all services. A statistical engine is then employed to detect anomalies, which the APM can then record and replay as part of an end-to-end tracing capability based on OpenTracing, an open API standard co-created by Sigelman and others that has now become a project administered by the Cloud Native Computing Foundation (CNCF).

    Other capabilities embedded within LightStep [x]PM include support for service mesh and load-balancing technologies such as Envoy, linkerd, nginx and haproxy.

    With every new era of enterprise computing, a contest occurs between startup companies such as LightStep and incumbent providers of technology platforms. LightStep is clearly trying to fill a void before incumbent providers of APM platforms can add support for microservices. Incumbents occasionally rely on their own organic efforts to upgrade their platforms, but more often they buy a startup company and then spend several years trying to unify disparate code bases.

    Of course, there are many organizations that are just beginning their DevOps journey. Many of the them may not have any kind of APM platform in place. Most tend to be cost-sensitive as well, so offerings based on open-source code tend to have greater appeal.

    However the APM wars play out, it’s apparent they are about to enter a new phase. The winners and losers of those wars will be determined by DevOps teams rather than C-level IT executives trying to impose a framework from on high. After all, if IT organizations have learned anything in the last few years, it’s that DevOps tends to have a more lasting impact when it comes from the bottom up.

    — Mike Vizard