staging-devopsy.kinsta.cloud

Tag: soa

  • Microservices Explained: Not Your Father’s SOA

    Microservices Explained: Not Your Father’s SOA

    Microservices are frequently referred to as a variant or derivative of service-oriented architecture (SOA), if not essentially the same thing. While there are similarities and both are designed around the concept of services, that’s where the similarities end. Each was created around a different set of principles and intended to address different problems.

    Microservices architecture is built around key concepts that, when applied, not only differentiate it from other architectures but deliver advantages that accelerate software delivery and help to scale large, complex applications. To deliver on the promise of cloud-native, microservices must be loosely coupled so that, ultimately, they are independently deployable. Any microservice can be updated and deployed—just that containerized microservice—without requiring changes to other microservice(s). Loosely coupled microservices mean they are not sharing databases or maintaining state, for example.

    How big should a microservice be? Or, in other words, how much should it do? The answers range from ‘a single thing’ to ‘a small set of related code with high cohesion’. Another factor is that getting too granular can overrun a microservices-based application with large numbers of microservices, increasing complexity and making triage through observability and tracing very challenging.

    Scaling microservices-based apps is another important factor. Autonomous microservices can be replicated and scaled for performance and workload using container orchestration tools such as Kubernetes.

    Microservice communications are achieved through well-thought-out APIs created around the business or operational capabilities the microservice provides to anyone or anything engaging through the API. The API, and data provided through the API, are often referred to as ‘technology-independent.’ It’s probably better stated that microservice APIs are built using approaches like RESTful and GraphQL over networks that are not tied to any one specific operating environment, technology or programming language. JSON, YAML and XML similarly represent data that is transferable across technologies.

    The following diagram of a media application demonstrates the principles of microservices architecture. Microservices for scheduling media, digital rights management, tracking impressions and adding new ad insertions are loosely coupled, autonomous and have well-defined API interfaces. Each microservice can be changed, enhanced and deployed rapidly and independently of other microservices.
    Microservices SOA

    Service-oriented Architecture, or SOA, emerged to solve a very different problem; the overwhelming size and complexity of monolithic applications. Monolithic applications have very large codebases that often don’t do a good job of compartmentalizing functional or business logic. This makes changes to the codebase challenging even to developers who know much of the codebase well.

    Services in SOA were often used to gather a collection of similar business logic together and then share them as a service with other parts of the application, as needed. Technologies like message buses are used to make requests of a service and operate as traffic managers for requests across multiple services and other parts of the application. While reusability was a critical design consideration, SOA services were still quite large, and deploying services at high velocity was not an important design consideration. SOA services often take considerable time to code and test the service including interdependencies across other parts of the application before deploying as part of a larger software release.

    One important note: There are benefits and drawbacks to microservices and SOA architectures; neither is ‘better’ than the other. Which architecture to use when mainly depends on the purpose of the application you are building. For larger, more complex enterprise application environments that require integration with many other applications, you might choose SOA. That’s a better fit than for smaller applications that don’t require middleware elements for managing the requests within the app or between other applications. Microservices, on the other hand, are better-suited for smaller and well-partitioned web-based systems. They are becoming the standard for today’s cloud-native applications, and also are a great fit for developing a mobile or web application because they give developers more control.

  • Microservices: The Advantages of SOA Without Its Drawbacks

    Microservices: The Advantages of SOA Without Its Drawbacks

    Service Oriented Architecture (SOA) was the great hope of organizations decades ago when they sought to advance legacy system integration, reduce and bypass layers, and rapidly access the system of record. At the time, the existing solution was point-to-point integration, creating a brittle “spaghetti” middle layer that was hard to manage. This was replaced by SOA, which was later augmented with ESB. This fixed the spaghetti mess by creating an intermediate set of layers, which added complexity to the integration process.

    Unfortunately, most IT departments with legacy systems and SOA still struggle to be as agile as needed in this ever-increasing global and digitized world. 

    SOA Solved Many Problems, But Not All

    Today, upward of 90% of the world’s enterprise applications are monolithic. When they were created, monolithic design was the best approach available. However, as business needs evolved and the demand for greater agility intensified, developers and IT teams are considering breaking free of these monolithic architectures.

    SOAs have become a hindrance, not the solution they once were.

    The SOA Integration Challenge

    The promise of SOA initiatives was extending the reach of core business functions while reducing the internal expenses and complexity that grew alongside monoliths. SOAs achieved these goals by breaking the core functions of a monolith into web services using protocols such as simple object access protocol (SOAP) and eXtensible markup language (XML).

    SOAP was built for universal application communications. Because it’s based on XML, SOAs designed with SOAP could, in theory, be used to create an agnostic integration layer. Rather than struggling to piece together various proprietary systems, these protocols would open monoliths on different operating systems so they could work together.

    This agnostic integration layer would let system administrators connect pieces of a monolith to an enterprise service bus (ESB) to achieve an agile, plug-and-play SOA. In some cases, this approach succeeded.

    A great deal of “legacy SOA” still provides value. In these cases, the value the SOA provides is the behind-the-scenes server-to-server communication that mostly aids developers. When it comes to serving internal and external customers–and their rapidly changing demands–SOA isn’t always up to the task.

    To achieve service integration, the ESB must oversee the messages from start to destination. This communication isn’t as simple as the SOA vendors may have promised. Consider an SOA integration within a core banking application. The message must go from the core application on the mainframe to a branch office server. If the business logic states a message is only relevant for one business day, administrators must decide whether to move it to a queue, log or disregard when the day passes. This is a common scenario for core banking applications in an SOA, but how well does it work?

    In this example–and others like it–the ESB must know whether a business day has passed to make the right decision about where to send the message. Therefore, the integration requires an algorithm–meaning that ESB cannot simply rely on a universal rule for sending messages between the monolith and external integration.

    When administrators introduce new business logic into the monolith integration, it turns what was supposed to be an agnostic service layer into a new application layer, increasing complexity. Instead of simply integrating the monolith into a new digital service, the enterprise ends up with a larger monolith–one that includes the mainframe and all the new integration stacks.

    Despite the promises of SOA, the integration problems result in increased maintenance time, greater complexity of code and software and the continued growth (not elimination) of monolithic applications.

    The first rule of effective integration is “smart end-points and dumb pipes.” Building logic and layers into the service layer breaks that rule, increases the overall complexity and adds another legacy application to your portfolio.

    Bottom line: Trying to optimize the SOA approach will only result in larger monoliths.

    Improving SOAs with Microservices

    Using microservice architectures helps realize the original promise of SOAs, delivering the benefits of SOAs while removing many disadvantages.

    For decades, CIOs have tried to transition away from monoliths by taking traditional approaches to integration, only to find they’ve doubled down on legacy investments. All these integration stacks end up coupled to legacy systems and only result in more work for the IT team–and a less agile organization.

    The integration step of SOA was never intended to include business logic. Trying to force business logic into this approach leads to workarounds and extra effort just to achieve a less-than-ideal result.

    The key factor is how to incorporate microservices without adverse effects. Luckily, microservices architecture can be forged from SOAs by introducing these new principles:

    •   Context Mapping: When replacing an existing SOA, teams must consider the size and scope of the new microservice and apply proper contextual boundaries. For example, SOAs that typically sought broad integration with digital services should be broken down into smaller domains to simplify operation.
    •   Shared-Nothing Architecture: Too many SOA integrations create sprawling dependencies that create complexity in the tech stack. Microservices avoid these cross-service dependencies. For those looking to move to microservices from an existing SOA, it’s important to look at the list of dependencies and work toward standalone functionality.

    Ultimately, the goal should be to refactor monoliths in a way that shifts the IT stack toward microservices. By taking the right approach, you can make the most of both microservices and APIs within your SOA. You enhance your digital journey, leading you to IT efficiency, faster cycles, greater scalability and competitive differentiation.

    — Zeev Avidan

  • 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

  • The Executive’s Guide to Microservices: Chapter 1

    The Executive’s Guide to Microservices: Chapter 1

    Meet Steve. Steve is responsible for a mission-critical application for a very large enterprise. He has a problem: It takes Steve and his team a very long time to make changes to this application and release it to production. Steve has been talking to vendors, consultants and peers about agile software development techniques and DevOps, but Steve and his team have assessed that his application does not lend itself to these approaches.

    See, the system Steve looks after is called a monolith, which is a very confusing title since it was developed using the latest modular software development approaches when it was created, in the latter half of the 1990s and early 2000s. Steve and his team are constantly advised that they need to decompose their monolith into microservices. However, this advice only confuses Steve and his team even more, since the system was designed using a service oriented architecture (SOA) with the intent of ensuring that it was easier to maintain and scale.

    Steve’s team fell into a very common trap associated with many SOA-based designs: The services were designed with deep dependencies, they share a common database and they are very coarse-grained. Indeed, the collections service, which is one of eight services in the system, handles every potential operation a collections agent might ever need. Modifying any operation within the collections service means the entire collections service must go through regression testing and production must enact a very cumbersome deployment strategy that requires a five-hour maintenance window.

    Needless to say, Steve cannot keep up with the requested changes from the business with these constraints. Steve’s advisers have given him some good advice on organizing to develop faster, but he would only be applying Band-Aids faster. However, once the constraints identified above had been pointed out to Steve and his team, they better understood the challenge ahead of them.

    Steve and team are going to have to redefine the data models so they support service independence, then extract subsets of functionality out of the large, intertwined services to deploy as within a well-defined business context—following the “do one thing well” mantra. They then can start to extricate the complex business logic trapped inside the enterprise service bus so it can be incorporated into the services at the edge.

    Steve and his team realize that continuing to enhance the monolithic code base avoids the challenges of redevelopment but reduces the value of that codebase to the business. While there will be a cost of untangling the monolith, the cost of not doing so is lack of competitiveness, lack of agility, long wait times for new features, possible opportunity loss and continued investment in technical debt. Steve’s job will be to present the justification for this to the business based on these risks.

    When the task is completed, Steve and team will be able to deploy new services and modify existing services within weeks. The costs related to development and testing will drop significantly and the finer-grained services will allow developers to address business needs more quickly.

    We’ll check in with Steve and his team as they embark on this journey and deal with the challenges ahead.

    — JP Morgenthal

  • SOA vs Microservices

    SOA vs Microservices

    Some say microservices architecture is proof that SOA is still alive. I contend that microservices architecture replaces SOA due to deficiencies in how SOA has been implemented as well as the original intent.

    In the mid-1990s there was a surge of investment for implementing enterprise applications to replace the aging homegrown legacy applications. These new applications managed complex activities around accounting, supply chain, human resource and manufacturing. They also were easy to integrate with other facets of the business, including existing legacy applications that were not going away and new and emerging web applications for customer and internal use.

    Out of necessity, there was a rise in the number of point-to-point integrations occurring. Over time, the web of point-to-point integrations became so complex to manage that even small changes resulted in major failures. To correct this problem, a category of software emerged to make integration easier by simplifying the control plane that focused on cataloging the endpoints, fostering connections and marshalling the data. These control planes were identified as enterprise application integration (EAI). Early EAI products did not inspect or act on the data.

    Somewhere along the line, vendors became aware that there was another underlying issue: The old system and the new system used different vocabularies and message structures. Initially, the consumer of the EAI tool output did the translation itself, but then vendors saw an opportunity to increase the capabilities of the EAI tooling to also become a data plane. So, then, the EAI tooling would also handle mapping and translation.

    Now, if your source systems never change, the value of an intelligent middleware that acted as a control and data plane seems both logical and of great value. However, when the source systems change, middleware comprised of dynamic routing and mappings from the source to the target becomes a considerable limitation. Any change to the source requires comprehensive regression testing on the entire system, and you must hope you have an example of every permutation of every message that may ever be delivered as input to ensure the change does not introduce future problems.

    Having been an integration consultant during this era, I can attest to weekly failures due to message combinations that no one had ever conceived of during testing.

    So, what does any of this have to do with SOA and microservices?

    The above approach I just described evolved with the products that acted as a control and data plane morphing into the enterprise service bus (ESB). The ESB became the cornerstone of the SOA strategy and together they formed the strategy for modernizing legacy systems. Hence, SOA, as it was ultimately delivered, ended up being an expensive mapping exercise from legacy data structures and messages to a newly appointed business language, also called the canonical representation. In some cases, these new SOA services would derive these new business data structures by querying and massaging data from multiple legacy systems, while in other cases, new business logic would be made available via the bus expanding the ecosystem of available capabilities.

    With SOA, the canonical message became the product of innovation and, hence, ultimately its downfall. Perhaps unfairly so, but, SOA never fostered continued modernization of the legacy systems into re-platformed and redeveloped services. It was about exposing the systems of record, both data and process, for inclusion into business processes, facilitating minimal changes to the legacy systems all handled through intelligent pipes.

    While digital transformation may be a popular concept that every business is now chasing, SOA’s failure demonstrates that simply exposing the existing systems was not enough to become the agile business we strive to be. Indeed, the systems of record that are brittle, burdened with technical debt and developed in a monolithic fashion were already impairing businesses’ ability to compete long before Uber and Airbnb came into existence. The appearance of these businesses just increased the urgency to address the legacy issue.

    Enter microservices architectures. First, I’ll reiterate my favorite soapbox topic: Putting a legacy app inside a Docker container does not in and of itself define a microservice. A microservice follows specific tenets of design. One of these tenets—and one that is very relevant to this discussion—is smart endpoints and dumb pipes. I find this design principle very interesting, considering what I’ve stated above about SOA. For me, it’s clearly a rebellion against SOA strategies.

    Also, I believe microservices approaches legacy modernization from a slightly different perspective. Microservices architectures by nature focus less on tooling (they’re polyglots by design) and more on the contextual bindings to business domains. Additionally, as someone eloquently stated on Twitter (which I cannot find now and so will paraphrase here), a microservice should be designed to be easily deleted without impacting the operations of the system. I believe the statement illustrates that a well-designed microservice isn’t intertwined with other services nor does it share intimacy of design.

    Some will debate—present company included—that this is what SOA was supposed to deliver. Unfortunately, this was not how it got implemented. So, this time we reduce the scope. Instead of a SOA service that represents the entire business domain, we deliver smaller, more well-focused entities representing subsets of the business domain. Subsequently, these services are designed to operate more independently, allowing them to better align with greater use of agile techniques.

    In microservices, architecture agility is the product of innovation. Ultimately, the improvements in speed, cost and quality are why microservices will succeed where SOA has failed.

    — JP Morgenthal

  • DevOps Debates: Monoliths or Microservices

    DevOps Debates: Monoliths or Microservices

    From the time software came into existence, application software has been booming to leverage the benefit of the computing paradigm. During this cycle, it has transformed decades of design and architectural thinking, and has crossed all aspects of application development and management needs, be it configurability, reusability, maintainability, scalability or security (a good list is of these “ilities” is here).

    While many have been addressed, one “ility” that has turned a lot of eyes and attention in the last few years is deployability. More than that, it is the ability to do so continuously. This requirement has changed the thinking of building software for two main reasons: (a) Businesses have started asking to release software faster than ever, even in verticals unheard of before; and (b) Cloud and infrastructure as code has made faster deployment a easier possibility. When you look at application design with deployability in mind, given the need to be agile, what you end up getting is a microservice.

    Most applications of old style addressed most “ilities” in an architecture but did not consider “continuous deployability” as a core need as well. I call these monolith from a deployment perspective. They are tightly coupled, and for any small change a complete build of the application was necessary.

    Now the question is, Should you really look at microservice as a silver bullet to deploy all software? Should you consider that as the de facto standard to deliver any application functionality? Will applications cease to exist the way we know? Here are my thoughts. As usual, feel free to add yours or write to me personally, as some of you do as well.

    Applications as monoliths will stay as they are

    1. Monoliths have evolved over generations of design and architecture tests and stood the test of time. The focus on modular development is, in fact, a way of creating modules, which are built with separation of concerns in mind.
    2. Monoliths were built to run for a long time. It had addressed some of the “ilities” well before they became considerations.
    3. Applications will remain easier to debug, as most of the debuggable areas are in developer’s hand, instead of having to work with a team.
    4. Applications will perform better, as they can share data in memory; they don’t have to do out-of-process calls to get one task executed.
    5. Applications will be more secure, as they will be a black box from an end user perspective or even a hacker perspective, with little coming out from the system.

    Microservices will be a monolith-killer all the way

    1. Deploy, deploy and deploy to correct your problems away. Fail fast and fix faster is the mantra that you can practice.
    2. It helps bundle two-pizza teams owning microservices and hence embrace better ownership and faster response.
    3. The overall architecture to deliver an end-to-end use-case may become complex, but each piece of the jigsaw puzzle can be handled faster.
    4. In the faster-moving world, business wants to try a concept rather thinking through all the “ilities” ahead of time, and progressively make everything better. Microservices helps abstract all complexities much better.
    5. Microservices will help developers think out of box from day one, while helping business deliver smaller chunks, without having to make the system a “big ball of mud.”

    At the end of the day, irrespective of the approaches, the key is to ensure the applications are managed well, changes are refactored well, the code that is written is readable and maintainable, and significant test assets are created to regress the entire system quickly. So whether it is a large system or microservices, you are able to make any necessary changes quickly and can deploy fast.

    While microservices surely will help this new faster-deployment thinking, I—and I am sure you all—have also seen large monolithic systems that are making delivery at an astounding pace.

    Thoughts?

  • What’s hot with DevOps

    What’s hot with DevOps

    DevOps as a movement to transform people, technology, processes for higher business value is here to stay. It’s disrupting organizational processes replacing the old with the new. Command and control IT, a historical approach to regulating tech top-down, is trending toward decentralization thanks to DevOps.

    Software source control is another such case. We saw Git take on the source control bigwigs and redefine how we collaborate and build software. Now, which other areas is DevOps disrupting?

    What’s hot with DevOps?

    Application services

    We have a famous saying in my home country Spain, The King is dead, long live The King! I say, “The application is dead, long live the application.” I’m referring to the practice of implementing applications as monoliths. Monolithic applications are a dying concept. Why? Because it’s better to design them as a collection of services that link together. Such a flexible structure allows service reuse and control at a granular level. And you manage their lifecycles independently. Attempting to control these services centrally though is the equivalent of trying to balance the federal budget.

    It’s challenging to manage the lifecycle of services because of the very nature of agile business decision-making. Since services are much more granular, managing their lifecycle is also such. That’s why current application lifecycle management tools do not scale for service-oriented applications. Next generation application lifecycle management requires a focus on the service not on the application.

    Microservices and Docker

    Microservices is to infrastructure what service-oriented architecture (SOA) is to applications. Next generation applications require agile infrastructure to sustain the cadence of faster releases. Microservices align infrastructure management to the much more granular world of application services.

    Over the last year, microservices gained traction fueled by the container revolution. The unit of infrastructure shrank from a VM to a container allowing applications to run as a composition of smaller self-contained services making application releases that much more agile. So my second bet is on containerizing application services.

    Hybrid and multi-cloud

    Third, cloud infrastructure management tools must scale to the next generation of the container and service-ready applications. In the world where infrastructure is a service, application architecture can no longer rely on infrastructure implementing a particular way. A development or QA environment does not have the same SLA needs or constraints of a production environment as an example. So applications must be able to run across a diverse infrastructure.

    The first generation cloud management tools focused on managing servers in public clouds. That focus made every infrastructure provider a special case. Special cases don’t scale though. The cloud management tools must scale by removing dependencies between applications and infrastructure. Thereby, infrastructure becomes a choice, not a dependency. Application services must be able to run in private, public, hybrid, or multiple cloud environments. Such elasticity and independence are what applications demand from infrastructure.

    Having been in this space for more than a decade now, I live and experience these DevOps trends daily. What are your thoughts, are there any trends you’re following closely?

  • 3 golden rules of microservices deployments

    3 golden rules of microservices deployments

    As a developer, you value the principles of SOA. You aspire to build applications as a set of consumable services via endpoints. Remember how Amazon used SOA to build the AWS platform and how Google is emulating AWS? However, not all is hunky-dory in the SOA world.

    Developing is one thing but running, managing, and maintaining services is a whole other beast. When it comes to the latter, many enterprises still act monolithic. They run and manage applications services as a unit on one or many servers. This approach fails to scale when the services themselves scale or when you need to update and maintain them regularly. So do you lament over the spiking costs and time spent on these efforts or fix the problem?

    Recent trends point to microservices as the answer. By definition, microservices are much smaller than services. In fact, Wikipedia says a microservice performs a small task often just one. There are many articles that go in deep about microservices architecture, but we cover an important part here, which is deployment automation. In other words, our daily job.

    The self-contained, independent, and reusable principles of microservice architecture help solve the problem of scaling and maintaining application services.

    • Self-contained. Microservices are standalone operations that run without requiring other services. That means each runs on its own. You can scale each up or down and replace a service individually instead of updating the entire monolith given the business need and load.
    • Reusable. Microservices are self-contained so you can reuse them for other applications and functions. We’re talking of reusing already deployed microservices.
    • Independent. Microservices are platform agnostic, which means you can design them independent of infrastructure needs to run anywhere, in any cloud.

    So is it easy to shift from SOA-based architecture to microservices? Adopting microservices is not without challenges. To name some, you need to modularize existing software services as self-contained units, you need to configure the microservices to communicate with each other, and you need lots of deployment and test automation.

    To address these challenges out of the box, we recommend a DevOps solution like ElasticBox. Take a look at how ElasticBox supports microservice deployments.

    1. Modularize self-contained microservices

    The box model in ElasticBox wraps each microservice as a standalone component in a service catalog that you can reuse across applications. A script box automates the lifecycle of microservices using Bash, Puppet, Chef, SaltStack, Ansible, PowerShell; a container automates Dockerfile deploys; a CloudFormation box automates AWS resource stacks.

    2. Connect microservices via bindings

    More microservices means more endpoints to manage. Such endpoints handle REST or other protocol communications over the network. With ElasticBox bindings, network references are as easy to manipulate as programming variables. Want to route database connections to another MySQL service? It’s easy to do. Just point the services to deploy with a different binding value.

    3. Deploy microservices independently

    Boxes are inherently agnostic. Put infrastructure metadata for CPU, memory, storage, additional disks, virtual networks, firewalls, load balancing, and autoscaling in deployment policies attached to a cloud service like AWS, Google cloud, and more. Policies help you deploy the microservices defined in the script boxes to any platform and cloud. The orchestration engine in ElasticBox interacts with the cloud APIs to auto-provision virtual machines based on metadata from deployment policies. So it’s easy to spin up and destroy microservices on demand without disrupting service availability.

    ElasticBox can simplify microservices deployments. For instance the Jenkins ElasticBox plugin continuously integrates ElasticBox automation with Jenkins jobs to test and deliver what the software developments teams build continuously. So the next time you think SOA, think microservices instead.  Feel free to check out how ElasticBox can help.