API World 2018

Service-mesh technology promises to deliver a lot of value to a cloud-native application, but it doesn't come without some hype. In this talk, we'll look at what is a "service mesh", how it compares to similar technology (Netflix OSS, API Management, ESBs, etc) and what options for service mesh exist today.

You are preparing to embark on a journey to service meshes. You have a full pack: Docker containers, Kubernetes orchestration, Istio/Envoy service mesh, and other essentials. You’re all set! Or are you? It’s no secret that sophisticated enterprises are using data to deliver new value and gain competitive advantage. As a result, applications and microservices produce, consume, and share massive amounts of data. Further, one of the common characteristics of a microservices architecture is the decentralization of data management, so data is distributed over a vast surface area. And of course all of this data needs to be controlled and protected for compliance with data security and privacy regulations such as PCI-DSS, HIPAA, and GDPR. What does this confluence of data-related trends mean for your journey to service meshes? An enterprise-class service mesh must account for data. For example, what data stores exist in the mesh? Where is the data located? What types of sensitive data are in the mesh? How is the data secured? Who is accessing the data? Before you start your journey to service meshes, learn how you should include a data-centric approach in your essentials from the beginning.

With the rapid adoption of microservices, Istio has become the de facto framework to load-balance, route, secure, and monitor the traffic that flows between microservices. This is accomplished in part through Istio’s service mesh, which provides a common networking, security, policy, and telemetry substrate for services. We will explain how the service mesh can help with the transition to microservices, empower operations teams, enable the adoption of security best practices. You’ll learn the history Istio and the service mesh concept and discover how you can easily leverage Istio for A/B testing, policy enforcement, secure communication, and observing your microservices deployment. Along the way, we will cover Istio’s ecosystem, the state of the project, where it’s headed, and how you can get involved.

• What is your definition of a service mesh?
• What problem does a service mesh solve? Why did the concept come about?
• What would you say is the number one pain point a service mesh helps with?
• What distinguishes the service mesh approach from other middleware mediators?
• Specifically, what is the difference between a service mesh and an ESB?
• Service mesh and an API Gateway/API Management?
• For companies looking to move to a service mesh, what is the right transition path? How would it vary depending on what they’re using today?
• Any situations where you wouldn’t recommend using a service mesh?
• What is the hardest part about implementing a service mesh? What about maintaining it?

Transitions from monolith to microservices are hard. While the number of blogs and books suggesting strategies to address this problem have grown exponentially, the essential tooling has improved slowly, with limited accessibility to developers.

To change this situation we at Solo.io developed Gloo, a platform to hybridize (or "glue") monolith-microservice-serverless environments and Sqoop, a codless graphQL server. 

Gloo enables multi-architecture and multi-cloud applications, by providing a suite of features to allow “glueing” components from any cloud (AWS, Azure, Google) and any backend (Kubernetes, Serverless, Consul, traditional VM) into a single user-facing API. 

Sqoop aggregates data from multiple backend sources into a single GraphQL API (with zero code written by the user).

Both projects are built on top of the Envoy proxy, and integrates out-of-the-box with other open-source projects including NATS, OpenTracing and more.

In this session, we will learn about Gloo, Sqoop and other open-source projects from Solo.io, and discover how its extensible architecture offers solutions to a broad range of use cases. Warning: lots of live demos will be shown.

Building Distributed Systems in the cloud is challenging, overcome those challenges using Reactive Systems utilizing Akka, CQRS, Event Sourcing and containers. Learn how "Reactive Microservices" helped the likes of Linkedin, CapitalOne and Verizon save millions of dollars on App infrastructure and accelerated time to market and performance in the process.

Capital One has been one of the rare large financial institutions that has been at the forefront of eagerly updating its core systems with cloud-native architecture and committing to developing most new applications using microservice architecture and containers. Having been on this journey for several years now, we can report that it is not for the faint of heart - it is full of dangerous operational time-sinks and genuinely challenging design implications. In this talk we'll share our take-aways covering wide range of important aspects: from team organization to infrastructure to design process, what we have learned and what still remains non-trivial. Spoiler alert - it was largely worth it.