Podcast – James Ferguson talks Kubernetes and the future as an Application Platform

Joining us this week is James Ferguson, Director of Cloud Consulting, JBC Labs.

About JBC Labs

Looking to automate your cloud and on-prem solutions? Needing to see faster CI/CD on AWS, GCP or Azure? Or perhaps ETL processing that makes your team and users of information more productive? JBC Labs has provided solutions for over 20 years to companies big and small. Our solutions make you run faster, more fluid, and provide a spark to drive your innovation. Our team are certified cloud architects and solution providers ready to help you today.

Highlights
• Overview of JBC Labs’ Jump Box Central Kubernetes Solution
• State of Kubernetes Today
• Concept of Kubernetes as an Application Platform
• Functions as a Service
• Service Mesh and Kubernetes

Topic                                                                                              Time (Minutes.Seconds)
Introduction                                                                                  0.0 – 1.24
Jump Box Central Name?                                                          1.24 – 2.06
Where are People Looking for Help in Kubernetes?            2.06 – 4.13
What Problem are you Looking to Solve?                              4.13 – 6.15
What Else Needed to Make Kubernetes Successful?          6.15 – 10.18
Sell Services for Kubernetes?                                                   10.18 – 12.09
Kubernetes Delivery Platform for Apps                                  12.09 – 15.37 (Hospital Example)
Why Function as a Service?                                                      15.37 – 19.05
Does Variety of Options Slow Down Adoption?                    19.05 – 20.05
Is FaaS an App for Kubernetes?                                               20.05 – 22.29 (PB & Chocolate)
Role of Service Mesh                                                                 22.29 – 29.06
Contact Information                                                                   29.06 – END

James Ferguson, Director of Cloud Consulting, JBC Labs.

James Ferguson has been involved in IT, Software Development and Business Management since 1992. During James Career he has created the worlds first mobile agnostic application for SAP and Oracle in the cloud, featured in Gartner and Forrester. Founded two companies and led many others. Industries James has helped companies ranging from Real Estate, Oil and Gas, Utilities, Finance, Insurance and Marketing. James currently helps customers as a principal architect and thought leader for the fortune 500 and SMB. James can be found on Linkedin, email, mobile, or out in the back country hiking.

Podcast – Oliver Gould on Service Mesh, Containers, and Edge

Joining us this week is Oliver Gould, CTO Buoyant who provides a service mesh abstraction view to micro-services and Kubernetes. Oliver and Rob also take a look at how applications are managed at the edge and highlights the future roadmap for Conduit.

Highlights

  • Defining microservices and Kubernetes from Buoyant viewpoint
  • Service mesh abstractions at a request level (load balance, get, put, …)
  • Conduit overview – client-side load balancing
  • Service mesh tool comparisons
  • Edge Computing discussion from service mesh view

Topic                                                                           Time (Minutes.Seconds)

Introduction                                                                0.0 – 1:39
Define Microservices                                                1:39 – 5.25
Define Kubernetes                                                     5.25 – 10.23 (Memory as a Service)
Service Mesh Abstractions                                       10.23 – 12.37 (L5 or L7)
Conduit Overview                                                      12.37 – 18.20 (Sidecar Container)
When do I need Service Mesh?                              18.20 – 19.55 (Complex Debugging)
Service Mesh Comparisons                                     19.55 – 22.31
Deployment Times / V2 to 3 for DRP                    22.31 – 25.13 (Kubernetes into Production)
Edge Computing                                                       25.13 – 27.04 (Define)
App in Cloud + Edge Device?                                  27.04 – 31.10 (POP = Point of Prescience)
Containers + Serverless                                            31.10 – 34.30 (Proxy in Browser)
Future Roadmap                                                       34.30 – 37.06 (Conduit.io)
Wrap Up                                                                     37.06 – END

Podcast Guest:  Oliver Gould, CTO Buoyant

Oliver Gould is the CTO of Buoyant, where he leads open source development efforts. Previously, he was a staff infrastructure engineer at Twitter, where he was the tech lead of the Observability, Traffic, and Configuration and Coordination teams. Oliver is the creator of linkerd and a core contributor to Finagle, the high-volume RPC library used at Twitter, Pinterest, SoundCloud, and many other companies.

.IO! .IO! It’s off to a Service Mesh you should go [Gluecon 2017 notes]

TL;DR: If you are containerizing your applications, you need to be aware of this “service mesh” architectural pattern to help manage your services.

Gluecon turned out to be all about a microservice concept called a “service mesh” which was being promoted by Buoyant with Linkerd and IBM/Google/Lyft with Istio.  This class of services is a natural evolution of the rush to microservices and something that I’ve written microservice technical architecture on TheNewStack about in the past.

servicemeshA service mesh is the result of having a dependency grid of microservices.  Since we’ve decoupled the application internally, we’ve created coupling between the services.  Hard coding those relationships causes serious failure risks so we need to have a service that intermediates the services.  This pattern has been widely socialized with this zipkin graphic (Srdan Srepfler’s microservice anatomy presentation)

IMHO, it’s healthy to find service mesh architecturally scary.

One of the hardest things about scaling software is managing the dependency graph.  This challenge is unavoidable from early days of Windows “DLL Hell” to the mixed joy/terror of working with Ruby Gem, Python Pip and Node.js NPM.  We get tremendous acceleration from using external modules and services, but we also pay a price to manage those dependencies.

For microservice and Cloud Native designs, the service mesh is that dependency management price tag.

A service mesh is not just a service injected between services.  It’s simplest function is to provide a reverse proxy so that multiple services can be consolidated under a single end-point.  That quickly leads to needing load balancers, discovery and encrypted back-end communication.  From there, we start thinking about circuit breaker patterns, advanced logging and A/B migrations.  Another important consideration is that service meshes are for internal services and not end-user facing, that means layers of load balancers.

It’s easy to see how a service mesh becomes a very critical infrastructure component.

If you are working your way through containerization then these may seem like very advanced concepts that you can postpone learning.  That blissful state will not last for long and I highly suggest being aware of the pattern before your development teams start writing their own versions of this complex abstraction layer.  Don’t assume this is a development concern: the service mesh is deeply tied to infrastructure and operations.

The service mesh is one of those tricky dev/ops intersections and should be discussed jointly.

Has your team been working with a service mesh?  We’d love to hear your stories about it!

Related Reading: