Category Archives: Compose

Podcast with Krishnan Subramanian on Edge, the Kubernetes Ecosystem & the Composable Enterprise

Posted on by
Reply

 

 

 

 

 

 

 

 

 

 

In this week’s L8ist Sh9y podcast Krishnan Subramanian, Founder and Chief Research Advisor of Rishidot Research talks about Edge Computing, the Kubernetes Ecosystem and the Composable Enterprise. Key highlights:

  • “Multi-Cloud is the foundation of Modern Enterprise” – Krishnan
  • Kubernetes ecosystem and the possibility that Serverless could replace it
  • IT innovation requires a composable and layered approach, without this approach IT will find themselves trapped in a hard-wired infrastructure unable to move forward

Topic                                 Time (Minutes.Seconds)

Introduction                                  0.0 – 1.28
Edge Computing                         1.28 – 4.25
What is the Edge?                       4.25 – 6.06
Use Cases Not For Cloud           6.06 – 8.50 (Networking and 5G)
Distributed Scale of Edge          8.50 – 10.03
Multi-Cloud Progress                 10.03 – 12.07
Supporting Diff Infra Types?      12.07 – 16.40
Multi-Cloud & Kubernetes         16.40 – 20.54
Kubernetes Ecosystem              20.54 – 28.00 (Serverless can replace)
Ecosystem Gaps                          28.00 – 29.44
Best of Bread IT                           29.44 – 32.25 (Composable Enterprise)
IT Moves to Smaller Units         32.25 – 35.30
Back to Edge                                5.30 – 41.45
Conclusion                                   41.45 – 42.35

 

Podcast Guest: Krishnan Subramanian
Founder and Chief Research Advisor, Infrastructure, Application Platforms and DevOps

Krishnan Subramanian (a.k.a Krish) is a well-known expert in the field of cloud computing. He is the founder and Chief Research Advisor at Rishidot Research, a boutique analyst firm focused on Modern Enterprise. Their open data-based research helps enterprise decision makers on their enterprise modernization strategy. His Modern Enterprise model helps enterprises innovate rapidly by transforming their IT as the core part of the innovation team. He was a speaker and panelist at various cloud computing conferences and he was also an advisor for Glue conference in 2011 and Cloud Connect Santa Clara in 2012. He has also organized industry-leading conferences like Deploycon and Cloud2020. He is also an advisor to cloud computing startups. He can be reached on Twitter @krishnan.

 

Surgical Ansible & Script Injections before, during or after deployment

Posted on by
Reply

RackN CEO, Rob Hirschfeld, has been posting about our unique composable operations approach with Digital Rebar to enable hybrid infrastructure and mix-and-match underlay tooling.

This post shows some remarkable flexibility enabled by the approach that allow operators to take limited, secure operations against running systems.

via Surgical Ansible & Script Injections before, during or after deployment. — Rob Hirschfeld

 

2015 Container Review

Posted on by
1

It’s been a banner year for container awareness and adoption so we wanted to recap 2015.  For RackN, container acceleration is near to our heart because we both enable and use them in fundamental ways.   Look for Rob’s 2016 predictions on his blog.

The RackN team has truly deep and broad experience with containers in practical use.  In the summer, we delivered multiple container orchestration workloads including Docker Swarm, Kubernetes, Cloud Foundry, StackEngine and others.  In the fall, we refactored Digital Rebar to use Docker Compose with dramatic results.  And we’ve been using Docker since 2013 (yes, “way back”) for ops provisioning and development.

To make it easier to review that experience, we are consolidating a list of our container related posts for 2015.

General Container Commentary

RackN & Digital Rebar Related

Faster, Simpler AND Smaller – Immutable Provisioning with Docker Compose!

Posted on by
4

Nearly 10 TIMES faster system resets – that’s the result of fully enabling an multi-container immutable deployment on Digital Rebar.

Docker ComposeI’ve been having a “containers all the way down” month since we launched Digital Rebar deployment using Docker Compose. I don’t want to imply that we rubbed Docker on the platform and magic happened. The RackN team spent nearly a year building up the Consul integration and service wrappers for our platform before we were ready to fully migrate.

During the Digital Rebar migration, we took our already service-oriented code base and broke it into microservices. Specifically, the Digital Rebar parts (the API and engine) now run in their own container and each service (DNS, DHCP, Provisioning, Logging, NTP, etc) also has a dedicated container. Likewise, supporting items like Consul and PostgreSQL are, surprise, managed in dedicated containers too. All together, that’s over nine containers and we continue to partition out services.

We use Docker Compose to coordinate the start-up and Consul to wire everything together. Both play a role, but Consul is the critical glue that allows Digital Rebar components to find each other. These were not random choices. We’ve been using a Docker package for over two years and using Consul service registration as an architectural choice for over a year.

Service registration plays a major role in the functional ops design because we’ve been wrapping datacenter services like DNS with APIs. Consul is a separation between providing and consuming the service. Our previous design required us to track the running service. This worked until customers asked for pluggable services (and every customer needs pluggable services as they scale).

Besides being a faster to reset the environment, there are several additional wins:

  1. more transparent in how it operates – it’s obvious which containers provide each service and easy to monitor them as individuals.
  2. easier to distribute services in the environment – we can find where the service runs because of the Consul registration, so we don’t have to manage it.
  3. possible to have redundant services – it’s easy to spin up new services even on the same system
  4. make services pluggable – as long as the service registers and there’s an API, we can replace the implementation.
  5. no concern about which distribution is used – all our containers are Ubuntu user space but the host can be anything.
  6. changes to components are more isolated – changing one service does not require a lot of downloading.

Docker and microservices are not magic but the benefits are real. Be prepared to make architectural investments to realize the gains.