devopsy.kinsta.cloud

Category: Microservices Journal

  • Transient Microservices

    Transient Microservices

     

    — ROELBOB

  • 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?

  • Microservices: Easier Than You Think

    Microservices: Easier Than You Think

    “Microservices are easier than you think and more valuable than you’ve heard.” Those are the words of Ben Gracewood, chief delivery officer at cloud POS and omnichannel retail provider Vend. His company has used microservices to trim a monolithic PHP application, improving performance and changing the way the company approaches updates.

    Approaching Microservices

    Vend is currently used by 15,000 retailers in more than 180 countries. It is aimed at inventory-based retailers—think housewares, fashion, grocery and so on. In addition to the usual POS and payments facilities, Vend handles loyalty schemes, gift cards and online storefronts. The company is based in New Zealand, with offices in London, Melbourne, San Francisco and Toronto. Engineering and DevOps is done in Auckland.

    Its global customer base means there is no maintenance window, and so live updates are essential.

    Vend’s HTML5 and iOS clients include caching and a local database to allow offline operation (the data is subsequently resynchronized), primarily to allow users to keep working in situations where there is no Internet connection. The main system was originally a monolithic PHP application.

    Vend executives had discussed the idea of migrating to microservices for about a year. But when the company’s vice president of Architecture experimented by writing one read­-only microservice that improved performance by orders of magnitude, “This was the ‘a-ha’ moment for us,” Gracewood says.

    Later, when Vend migrated from Rackspace to Amazon Web Services, it used a routing microservice that directed traffic to whichever cloud held that particular customer’s data at the time. That allowed a progressive migration with no disruption for customers.

    Those initial successes showed Vend it should move more seriously in that direction. Nine months later, the company had 12 microservices in production.

    Vend is now adding them at the rate of about two per month, and the monolithic PHP system has been slimmed and surrounded by a cloud of microservices. An Nginix-based routing layer allows existing URLs to be redirected to microservices where appropriate.

    The company has followed DevOps practices from the outset, but its first few microservices were deployed and managed as special cases. Now, both the PHP monolith and all the microservices are within the DevOps tent.

    Adoption Dos and Don’ts

    When it comes to adopting microservices, “It’s never too soon to start,” says Gracewood. “It doesn’t have to be all or nothing,” despite what you might hear from other microservices veterans—everyone has been partway through their journey at some stage.

    Gracewood’s advice is to build your first microservice and do what you have to in the development of your DevOps practice. Then keep iterating.

    Don’t fall into the trap of thinking a microservice has to be 100 percent complete before it can be deployed, he says. Start by developing the minimum functionality required at the outset, and then increasing its sophistication over time. Since a change to a microservice affects a relatively small part of the entire system, the continuous update model is easier to apply to microservices than monolithic applications.

    That point also has an organizational impact: A microservices architecture and DevOps support Gracewood’s philosophy of trusting engineering and development teams to implement the right things at the right time. With monolithic software, a mistake or a poor decision can have wide-ranging repercussions, so considerable oversight is required. But the nature of microservices keeps issues localized, so if an issue does somehow slip through the testing process, it is easier to revert to the previous version.

    Adopting DevOps and microservices does require a certain amount of education, Gracewood notes. Engineering teams must understand the command line, Docker and so on. Making the move calls for “lots of tooling or lots of training,” he says. To that end, Vend has built some custom tools.

    Gracewood’s final tip for organizations thinking of adopting microservices: “Log everything [and] apply metrics to everything,” right from the start. You need to know how people are using your system. In particular, identifying the most heavily used microservices will reveal the areas where efforts to improve performance are likely to yield the best returns.

  • DevOps and the Challenge with Services

    DevOps and the Challenge with Services

    At RackN, we’ve been working for years to make DevOps portable across platforms. For us, that means the ability to move between clouds and from cloud to metal. Of the several challenges to portability—composability, API heterogeneity, sequence, cross-system dependencies—making configuration management tools work with services has been particularly important, as significant parts of building systems rely on services that are not directly configurable.

    Let’s look at DNS as an example. Whenever we configure services on a node, there are DNS implications. If we bring up a web server, we want to use a logical name for the node. If it’s a secure web server, that name should match our certificate. If we want to make that service discoverable, we likely want to add a logical name for that node, such as “clustermanager6.example.com” or similar. If you include names for BMC and rack location—not to mention IPv6 naming—it’s easy to image nodes with 10 names. Even cloud nodes have similar issues. That’s a lot of entries to manage!

    The problem with all those DNS names, and similar services, is that they are NOT configurable from the node. They are services with APIs that require restricted authorization.

    Services and Automation

    DNS is just one simple example.  System-level DevOps has many places where the configuration workflow needs to include external service actions. In cloud environments, generally that means either writing pre- or post-configuration steps that talk to the specific cloud API or using one of the cloud-specific template files. In physical environments, generally that means a lot of added manual steps or tightly constraining automation to inventory map files. No matter what, nodes don’t own DNS configuration—it’s a node external service with the API elements that are site specific.

    All of these approaches make DevOps brittle and site-locked. Five years ago that was okay, when choices were more limited and scripts were hand-crafted by DevOps artisans. Today, we need our automation to be robust, portable and transparent.

    We realized system automation needed to treat services interactions as equal to configuration. That means when we’re working on provisioning, we make sure service steps can be woven into the sequence of configuration steps. They must not be assumed correct or delegated to pre- or post-conditions because that makes it impossible to test and re-create working environments.

    What can you do? We’ve found service registration tools (we like Consul.io) are essential and relatively easy to implement to help track services that we manage or proxy. More broadly, we’ve been working in the open on Digital Rebar to blend configuration and services into a single workflow.

    The first step is to re-examine your configuration management scripts (and their prerequisites) for hidden service API interactions. Exposing those external dependencies will help you improve your automation repeatability and portability.

  • How to Handle DevOps Microservices (Hint: Carefully)

    How to Handle DevOps Microservices (Hint: Carefully)

    Given the dizzying amount of best-of-breed tools that can be involved in the development pipeline, a well-written microservice comes to the rescue with just enough code to keep things running. But too much of anything is never good. Here’s how and when to use microservices.

    Microservices are all the rage right now: these mini-apps are being used to integrate distributed applications that can be modified more easily. Microservices act like the glue, holding together processes and systems in the DevOps automation workflows. This means faster, more automated cycles, better implementation of continuous delivery and increased visibility into DevOps processes and deployments.

    For developers and testers, who generally love the best-of-breed approach of using whatever tool they prefer for the job, microservices allow them to do that by affordably connecting many different open-source and commercial tools in the DevOps pipeline. While some of these tools have built-in integrations to other popular tools, those integrations may not be exactly customized for your needs. Asking the vendor to build custom integrations for you can be cost prohibitive and may not be feasible within the time frame your organization is looking to implement.

    So with microservices, development teams have the flexibility to build their own tool stack and integrate everything to achieve full visibility into the development process. Equally helpful, REST APIs are super easy to work with compared with legacy APIs; developers can handle writing microservices without specialized expertise in the products that are being integrated. These are just a few of the extremely powerful advantages of the microservices approach.

    Yet as with every other cool technology, there are a few hitches, as follows:

    1. Hard to handle. Microservices depend upon vendor APIs, and when those change, the service will break. Then, you’ve got to rebuild the service from scratch. That is a time-consuming task that detracts from the main job at hand: writing and refining code. In an environment with hundreds of microservices, pretty soon, you’ve got developers spending the bulk of their time updating those pesky mini-apps in your devops pipeline instead of building new user features. Costs escalate and timelines slip.
    2. Slapdash processes. Let’s face it, when you’re writing a microservice just for your team, you’re going to do it as quickly as possible, thereby skipping a few steps that can make the microservice less fragile. A vendor, meanwhile, writes a micro-service to help hundreds of customers – therefore, it’s got to be bulletproof. The internal approach for integration through microservices can be more prone to breakage. Once one service breaks, there is the inevitable domino effect with other integration points, meaning down time in your development process.

    So, now what? It’s possible to make all this a bit easier. First, make sure that you’ve got the economics straight. Will developing microservices as your integration strategy be cheaper (factoring in staff time) than having vendors do it for you? If cost is not the main consideration, do the benefits of having a custom-built DevOps tool stack outweigh the complexity issues including downtime risks when a service breaks? Is there a clear-cut benefit from having a custom integration over taking the vendor’s not-quite-perfect integration? Do the analysis before choosing the microservices path – and remember to tie all this back to business benefits.

    Here are some ways to reduce the complexity of microservices:

    Go hybrid: In most cases, organizations will find that using a combination of vendor integrations and microservices is often the answer.

    Outsource: For business-critical applications, it’s not a bad idea to let an outside development firm handle the microservices portion for you. That will reduce your risk and free up your developers to focus on building products not managing integrations.

    Tools and languages: Choose languages for writing microservices that work well with REST APIs, such as Python and Ruby. As well, keep an eye out for tools that can help when you’re doing this in-house, such as Zapier or TaskTop. We expect those automated options to only grow, as companies expand their use of microservices and containers to optimize their DevOps operations.

    About the Author/Kevin Dunne

    AAEAAQAAAAAAAAPqAAAAJDcwMjVkYzMyLTQ1ZGQtNDAwNC1hNWRkLTVjZGJmYTNlZGQwNAKevin Dunne is the vice president of strategy and business development at QASymphony. He has a deep interest in the emerging trends in software development and testing. Kevin joined QASymphony from Deloitte, where he managed testing on large government and Fortune 500 engagements delivering ERP implementations and custom software development. He can be found online at LinkedIn and Twitter.

     

  • Microservices, Hyper-Complexity, and Automation

    Microservices, Hyper-Complexity, and Automation

    Imagine building a human being one DNA codon at a time. Sure, you might be able to build a pretty awesome individual. But it would take a long, long time. And you’d only be able to build one. Worse yet, if you didn’t get your person exactly right on your first try, it would take you another long, long time to come up with Version Two.

    Unfortunately, this is exactly the position many companies are putting themselves in with microservices.

    Yes, microservices theoretically enable companies to adaptively recombine their digital DNA to build the increasingly awesome apps. But without better automation, they won’t be able to do so very quickly—or very reliably.

    Hyper-Complex DevOps

    Microservices introduce significant additional complexities into the DevOps lifecycle. Each microservice has its own data mappings, APIs, latency/performance dependencies, etc. So, while microservices may offer genuine advantages in terms of adaptability and re-use, they also multiply the total number of discrete DevOps tasks—especially vis-à-vis test/QA—by at least one full order of magnitude.

    This is a serious problem for shops that aren’t sufficiently well-automated, because any task—or, as is much more often the case, any handoff between tasks—that is not well-automated will quickly turn into a bottleneck.

    The resulting adverse consequences of insufficiently automated microservices DevOps can thus include slow delivery, excessive cost, and mistakes. Worse yet, chronic bottlenecking will likely create a pervasive organizational disincentive that fundamentally undermines the microservices initiative itself.

    What Automation Entails

    Thorough, effective DevOps automation is, of course, more easily aspired to than achieved. To implement the kind of end-to-end DevOps automation required for microservices success, organizations have to get three things right:

    • Process mapping. Effective automation requires an exhaustive definition of process. This exercise is not for the faint of heart—because most organizations have many pockets of ad hoc process at various points in the DevOps cycle. Test/QA tends to be especially variable based on factors such as the delivery pressure teams are under at any given time.
    • Automation technology. Development teams often use scripting and other technologies to automate various DevOps tasks. An overly fragmented automation environment, however, can be difficult to orchestrate and manage. So the move to microservices may necessitate a more holistic integrated automation environment.
    • Leadership and culture. A well-automated DevOps process alone is insufficient for microservices success, because it is unfortunately not true that “if you build it, they will come.” On the contrary, a strong leadership commitment is essential for changing the way people work.

    The application economy is putting development organizations under intense pressure to be more productive and responsive to ever-changing market dynamics. Microservices offer one possible way to respond to that pressure. But microservices won’t work without a much more rigorous approach to DevOps automation. IT leaders may therefore want to focus on automation first and microservices second, instead of the other way around.

    Unless, that is, you only want to build one app using microservices—and then maybe build a slightly better one a few months later.

  • 4 big challenges of microservices

    4 big challenges of microservices

    The rise of microservices as a means of developing and delivering software value faster is clearly on the rise. Containers have skyrocketed from a fringe technology to a mainstream imperative and organizations are scrambling to jump on the microservices bandwagon. Before you rush out to embrace microservices, though, there are a few things you should keep in mind.

    First let’s talk about what microservices even are since it’s a relatively new term in a sea of relatively new terms.

    Al Hilwa, research director, Application Development Software at IDC described microservices this way:

    “Microservices is an architectural approach that draws on long evolving experience in software engineering and system design, including the SOA efforts of the last two decades. Microservices architecture is enabled by a spectrum of tool categories but is primarily an architectural approach to system design that also requires considerable organizational and cultural adjustment to execute successfully.”

    Put more succinctly, microservices is an evolution of software development and deployment that embraces DevOps and containers and breaks applications down to smaller individual components. Organizations can develop and deploy faster because there is a modular approach that makes code more efficient and enables much of the common or routine elements to be automated.

    Everyone seems to be doing DevOps and containers these days. If you’re not you may feel like you need to catch up quick or risk being left in your competitors’ collective dust. That may be true to some extent, but you have to approach microservices in the right way and for the right reasons. Jinesh Parekh, CEO of Idyllic Software, shared some thoughts about four challenges organizations should consider when venturing into the world of microservices.

    1. Insufficient guidance

    When it comes to implementing new technologies and embracing new strategies it can be a little like the “Wild West”. There are few hard rules in place and very little in the way of guidelines or documentation to help you navigate how to build and deploy software using microservices. Thankfully, sites like devopsy.kinsta.cloud and ContainerJournal are here to provide as much information as possible to give organizations some guidance.

    2. Getting it wrong

    There are a variety of “moving parts” involved in doing microservices successfully. Your organization should adopt a DevOps culture and have the appropriate infrastructure in place to avoid getting it wrong. Microservices architecture is generally built on a foundation of cloud and virtualization, and relies heavily on automation to ensure success and avoid failures.

    3. No going back

    You should be aware that it’s exceptionally difficult to switch back once you start down the microservices path. The changes that have to happen in terms of culture, tools, and processes to embrace microservices are not easily undone. The good news is that there is very little—if any—reason an organization would move to DevOps and containers as a development framework and then decide to revert to the old, monolithic way of doing things.

    4. Deliver value

    Parekh’s focus on delivering value is biased toward Idyllic Software. His company is in the business of delivering applications for clients via microservices and Parekh suggests that organizations outsource development to an experienced leader to ensure microservices meets expectations. You don’t necessarily have to outsource to Idyllic Software, though, or outsource at all. You just need to make sure that your approach to microservices benefits your organization—that it adds value and meshes with business objectives and isn’t just microservices for the sake of following the microservices trend.

    Microservices seems to be here to stay, and seems to be on the same path as DevOps and containers from niche concept to mainstream business adoption. As you ramp up to jump on the microservices bandwagon just make sure you keep these things in mind.

  • DevOps Leadership Series: Monitoring Containers and Microservices

    DevOps Leadership Series: Monitoring Containers and Microservices

    Trevor Parsons (@trevparsons) is a Co-Founder and Chief Scientist at Logentries, a leading SaaS-delivered log management and analytics service. I caught up with Trevor at the Velocity Conference in Santa Clara and asked him what themes were resonating with attendees this year.

    For this episode of the DevOps Leadership Series, Trevor briefly illustrates some current problems with state of microservices and container-based architectures, while sharing a positive outlook for the future.

    https://www.youtube.com/watch?v=zHRE4011WVk

    Trevor says there’s been a lot of development in how to log and monitor containerized systems and he sees better support from Docker for logging, showing an increasing focus on this topic in 2015 and beyond. He anticipates the next year to have huge improvements in managing and monitoring these new systems and architectures.

    Next up in the DevOps Leadership Series, I headed to London for the DevOps Connect: Rugged DevOps event, where we’ll discuss more about Rugged DevOps practices.  In London, I was able to catch up with Helen Beal (Ranger4), Justin Arbuckle (Chef), and Gareth Rushgrove (Puppet Labs).

    If you have missed any of the other videos from this series, you can find them here.  (We’re up to 15 so far).

  • 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.