Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Adrian Cockcroft on the Challenges of Managing Microservices

Adrian Cockcroft on the Challenges of Managing Microservices

This item in japanese


Adrian Cockcroft's devopsdays Amsterdam 2015 keynote addressed how CIOs' key goals - align IT with business, develop products faster, avoid security breaches - are attained through the adoption of DevOps practices and Continuous Delivery with containerized microservices. But managing microservices poses new challenges. Cockcroft proposes simulation as a solution to some of those challenges.

Monolithic applications are adequate for small teams that use a common programming language, or when efficiency and low latency are paramount. But immutable, containerized, microservice deployments, within a context of Continuous Delivery is the big disruption. Cockcroft claims that they scale, allow for faster development and support the diverse platform environments that come with growth.

The atomization of software with the advent of microservices brings management challenges. Visualizing the flow through possibly, hundreds of services, understanding failures and testing monitoring tools are the big challenges to face. How to cope with all those services that are continuously deployed and live in ever more ephemeral hosts? A few years ago, bare metal servers who took many weeks to provision and which then were live for years were the norm. Nowadays, containers take seconds to deploy and live for minutes or hours. AWS Lambda responds in milliseconds and lives for seconds.

Cockcroft believes that simulation must be part of the solution, so he built spigo, now called simianviz: SIMulate Interactive Actor Network VIsualiZation. Simianviz main goal is to:

  • Generate test microservices configurations/architectures at scale
  • Stress monitoring tools display capabilities

Simianviz simulates architectures in a simple desktop, using a JSON description to model those architectures:

    "arch": "netflixoss",
    "description":"A very simple Netflix service. See to decode the package names",
    "version": "arch-0.0",
    "victim": "homepage",
    "services": [
        { "name": "cassSubscriber",   "package": "priamCassandra", "count": 6, "regions": 1, "dependencies": ["cassSubscriber", "eureka"]},
        { "name": "evcacheSubscriber","package": "store",          "count": 3, "regions": 1, "dependencies": []},
        { "name": "subscriber",       "package": "staash",         "count": 6, "regions": 1, "dependencies": ["cassSubscriber", "evcacheSubscriber"]},
        { "name": "login",            "package": "karyon",        "count": 18, "regions": 1, "dependencies": ["subscriber"]},
        { "name": "homepage",         "package": "karyon",        "count": 24, "regions": 1, "dependencies": ["subscriber"]},
        { "name": "wwwproxy",         "package": "zuul",           "count": 6, "regions": 1, "dependencies": ["login", "homepage"]},
        { "name": "www-elb",          "package": "elb",            "count": 0, "regions": 1, "dependencies": ["wwwproxy"]},
        { "name": "www",              "package": "denominator",    "count": 0, "regions": 0, "dependencies": ["www-elb"]}


After running a simulation of the architecture, simianviz is able to produce visualizations. Here is an example of standard LAMP stack architecture that includes  DNS, load balancer, web servers, MySQL and memcached:

Product Management Processes

Cockcroft also gave product management advice to support the CIO's goals of aligning IT with business, developing products faster and avoid security breaches.

Even in a agile world, the assumption that processes are the way to prevent problems is still common. Cockroft advises to look out for "scar tissue" processes. They are the ones that denounce everything that went bad in the past, as they were added to prevent specific incidents. If you have too many rules you cannot follow them all. Netflix's main rule is "do what's in the best interest for the company".

To support the CIO's goals, Cockcroft suggests that one very good option is to abolish the role altogether, ensuring that "business", or "product", and "IT" all work together. Netflix, for instance, doesn't have a CIO, only a Chief Product Officer.

Cockcroft proposes to organize IT around two types of teams. "Platform" teams provide the APIs for platform/infrastructure automation: they need system, network and SAN admin skills. "Product" teams who use microservices architectures to build the product. The "product" teams should have skills that range from product management, through UX, Dev and QA to DBA skills. Cockcroft puts an emphasis on safety, asserting that "insecure applications behind the firewall are not secure". Devs should build rugged software, using tools such as Gauntlt to test security requirements, for instance.

As others, Cockcroft argues that on-call activities should be assigned to the ones who built the product ("you build it, you run it"). But the responsibility should not end there, the whole hierarchy (managers and upwards) should act as backups. This is a crucial premise to ensure that software is reliable.

Rate this Article