Making sense of microservices, service mesh, and serverless

My presentation for 2012's Cloud Connect that goes over architectural and design patterns for open and scalable clouds. Technical deck targeted at business audiences with a technical bent.

마이크로서비스 아키텍쳐, 컨테이너를 활용한 클라우드 네이티브 어플리케이션을 개발할 때 참고할 만한 레퍼런스 아키텍쳐와 개발 패턴에 살펴봅니다. 특히 전통적인 Netflix/OSS와 Spring Cloud이외에 다양한 패턴등에 대해서 알아봅니다.

Some problems with monolithic architecture, the microservice's best practices and their drawbacks. How build microservices? How to prepare your Operations teams for microservices?

Cloud Native Application과 관련 기술 소개

Google의 Kubernetes에 대해서 간단하게 정리 해봤습니다.

This document discusses service meshes and provides examples of popular service meshes like Linkerd and Istio. It defines a service mesh as a dedicated infrastructure layer that handles service-to-service communication and provides traffic management, observability, and policy enforcement. Benefits of a service mesh include discovery, load balancing, failure recovery, metrics, monitoring, and access control. Popular service meshes like Linkerd and Istio are then described in more detail.

This presentation outlines the benefits of implementing a Microservice over a monolithic architecture.

西脇 雄基（LINE)/Rancher 2.0 Technical Deep Dive 2018/7/28 LINE Developer Meetup in Tokyo #40 -Kubernetes- https://line.connpass.com/event/92049/

( Microservices Architecture Training: https://www.edureka.co/microservices-... ) This Edureka's Microservices tutorial gives you detail of Microservices Architecture and how it is different from Monolithic Architecture. You will understand the concepts using a UBER case study. In this video, you will learn the following: 1. Monolithic Architecture 2. Challenges Of Monolithic Architecture 3. Microservice Architecture 4. Microservice Features 5. Compare architectures using UBER case-study

Microservices and containers are now influencing application design and deployment patterns. Sixty percent of all new applications will use cloud-enabled continuous delivery microservice architectures and containers. Service discovery, registration, and routing are fundamental tenets of microservices. Kubernetes provides a platform for running microservices. Kubernetes can be used to automate the deployment of Microservices and leverage features such as Kube-DNS, Config Maps, and Ingress service for managing those microservices. This configuration works fine for deployments up to a certain size. However, with complex deployments consisting of a large fleet of microservices, additional features are required to augment Kubernetes.

AWSKRUG Architecture 세미나 22회차 발표자료 당근마켓의 IaC를 살짝 엿보면서 라이트닝토크를 위한 발표자료입니다.

애자일, 크로스 기능팀과 같은 개발 트렌드의 변화와 요즘 유행하는 마이크로 서비스 아키텍쳐에 대해서 알아본다.

본 강연에서는 금융 감독원의 클라우드 이용 가이드라인에 맞추어 바로 도입 가능한 HPC, 빅데이터, 백업, VDI 등의 업무에 대하여 간단하게 소개하고 AWS 상에서 구축하기 위한 참조 아키텍쳐와 특장점 및 고객 사례에 대해 설명해 드릴 예정입니다. 연사: 정영준 솔루션 아키텍트, 아마존 웹서비스

Kevin Huang: AWS San Francisco Startup Day, 9/7/17 Architecture: When, how, and if to adopt microservices - Microservices are not for everyone! If you're a small shop, a monolith provides a great amount of value and reduces the complexities involved. However as your company grows, this monolith becomes more difficult to maintain. We’ll look at how microservices allow you to easily deploy and debug atomic pieces of infrastructure which allows for increased velocity in reliable, tested, and consistent deploys. We’ll look into key metrics you can use to identify the right time to begin the transition from monolith to microservices.

2015년 AWS Partner TechShift

- Microservices architecture breaks applications into small, independent services that focus on specific tasks and communicate over well-defined interfaces. This improves scalability, flexibility and allows for independent development and deployment of services. - The architecture promotes separating concerns, with each small service handling a single "verb" of the application and teams owning service groups. Services are stateless and communicate asynchronously over lightweight protocols. - Automating deployment through containerization allows for easy rollout of new versions with zero downtime and elastic scaling of services based on demand. Monitoring provides visibility into technical and business metrics of the distributed system.

40 DevSecOps Reference Architectures for you. See what tools your peers are using to scale DevSecOps and how enterprises are automating security into their DevOps pipeline. Learn what DevSecOps tools and integrations others are deploying in 2019 and where your choices stack up as you consider shifting security left.

A presentation on why or why not microservices, why a platform is important, discovering how to break down a monolith and some of the challenges you'll face (data, transactions, boundaries, etc). Last section is on Istio and service mesh introductions. Follow on twitter @christianposta for updates and more details

This document discusses transitioning from monolithic applications to microservices and serverless architectures. It begins by defining technical debt and explaining how microservices can help pay it down incrementally. It then covers different architectural styles like monoliths and microservices. The rest of the document discusses moving to cloud infrastructure, breaking apart monolithic applications into independent services, communication between services, leveraging third-party services, and security considerations for microservices.

We consider a microservices architecture to achieve an end goal, not because it's "the cool thing to do". Every organization looking to adopt this architecture must realize (and adhere) to a set of foundational principles. Guided by those principles, we can correctly choose the technology to help support a microservices architecture and meet our end goals. This talk explains those core principles and gives you the tools needed for your microservices journey.

This document provides an overview of microservices from Christian Posta, a chief architect at Red Hat. It discusses what microservices are, reasons for using them, common microservices patterns and frameworks, decomposing monolithic applications into microservices, and ensuring resilience between services. The presentation also covers using Kubernetes and OpenShift for microservices and demonstrates sample applications.

When building microservices, you must solve for a number of critical functions, but the process can be incredibly complex and expensive to maintain. Christian Posta offers an overview of Envoy Proxy and Istio.io Service Mesh, explaining how they solve application networking problems more elegantly by pushing these concerns down to the infrastructure layer and demonstrating how it all works.

This document summarizes one organization's journey from a monolithic application architecture to a microservices architecture. It describes some of the pains of maintaining a monolithic application. It then discusses strategies for breaking the monolith into independently deployable microservices at low risk, including identifying module boundaries, deploying and releasing services independently, virtualizing data integration, and using traffic mirroring. The goal is to increase development velocity while lowering risk.

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.

We consider a microservices architecture to achieve an end goal, not because it's "the cool thing to do". Every organization looking to adopt this architecture must realize (and adhere) to a set of foundational principles. Guided by those principles, we can correctly choose the technology to help support a microservices architecture and meet our end goals. This talk explains those core principles and gives you the tools needed for your microservices journey.

Building useful services across our collection of existing applications, microservices, and now functions, we see a common theme: services must be able to communicate with each other, and solve problems like data mediation, routing, policy enforcement, security, and others. Service mesh is a technology that has emerged in container-based environments to help solve some of these problems; however, not all of them can be solved by pushing the problems to a different abstraction. Understanding the role and responsibility of service mesh and application-integration frameworks can help you successfully build useful business services on a cloud native platform. This talk will help you understand those roles and responsibilities and how service mesh and application integration co-exist to build cloud native applications.

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.

Cloud-native describes a way of building applications on a cloud platform to iteratively discover and deliver business value. We now have access to a lot of similar technology that the large internet companies pioneered and used to their advantage to dominate their respective markets. What challenges arise when we start building applications to take advantage of this new technology? In this talk we'll explore the role of service meshes when building distributed systems, why they make sense, and where they don't make sense. We will look at a class of problem that crops up that service mesh cannot solve, but that frameworks and even new programming languages like Ballerina are aiming to solve

The document provides an overview of microservices including: - Defining microservices and comparing them to SOA - The benefits of a microservices architecture like improved agility, scalability, and innovation - Common microservice patterns on AWS like serverless and container-based services - How microservices can address business problems like long feature cycles and technical problems like lack of testability - A customer story of how MYOB adopted microservices on AWS to support their online products - Tips for evolving architectures including focusing on automation, organizational structure, and individual service design.

In this presentation shows you how the benefits of AWS technologies can be combined with a new approach to Development and Operations. It’s all about delivering new features and functionality faster, without compromising reliability, stability and performance. * Understand the challenges faced by traditional Development and Operations teams * Apply Continuous Integration/Delivery processes and tools to enable change * Appreciate how various AWS technologies can be used to facilitate DevOps

Microservice oriented architectures have been implemented and deployed by many and are on the near-term agenda of many others. However, the distributed nature of microservices is a double edged sword, being the source of many of the benefits, but also the source of the pain and confusion that teams have endured. We will review best practices and recommended architectures for deploying microservices on AWS with a focus on how to exploit the benefits of microservices to decrease feature cycle times and costs while increasing reliability, scalability, and overall operational efficiency. Speaker: Craig Dickson, Solutions Architect, Amazon Web Services Featured Customer - MYOB

Machine learning applications are typically stitched together from hopes and dreams, shell scripts, cron jobs, home-grown schedulers, snippets of configuration clipped from multiple blog posts, thousands of hard-coded business rules, a.k.a. "our SQL corpus," and a few lines of training and testing code. Organizing all the moving parts into something maintainable and supportive of ongoing development is a challenge most teams have on their TODO list, roadmap, or tech debt pile. Getting ahead of the day-to-day demands and settling into a sane architecture often seems like an unattainable goal. The past several years have seen an explosion of tool-building in the data engineering and analytics area, including in Apache projects spanning the areas of search and information retrieval, job orchestration, file and stream formats, and machine learning libraries. In this talk we will cover our product and development teams' choices of architecture and tools, from data ingestion and storage, through transformations and processing, to presentation of results and publishing to web services, reports, and applications.

Developers are excited about serverless computing, and rightfully so. With serverless, developers can spend more time writing code and less time worrying about, you guessed it, servers! But is serverless the right abstraction for every workload? How does serverless differ from an application platform? And despite the name, there need to be servers somewhere … Who’s managing them? Join us for a look at serverless computing and what it means for both developers and operations teams in the enterprise. In this webinar, Guest Speaker Forrester VP and Principal Analyst John Rymer and Pivotal’s Mark Fisher will cover: - What serverless is (and what it isn’t) - The current serverless open source and market landscapes - How serverless fits into modern application infrastructure - What workloads are best suited to serverless (and which aren’t) - Advice to developers (and operations teams) for getting started with serverless Presenters : Mark Fisher, Pivotal and John Rymer, Forrester

This document introduces Microsoft Flow and Azure Functions. It provides an overview of each tool, including how Flow allows non-developers to create workflows across various services, while Azure Functions allows developers to write pieces of code that can be triggered to run in the cloud. The document also demonstrates how to build a workflow in Flow and create a function in Azure. It discusses best practices for integrating Flow and Functions together through webhooks or APIs.

This slide is translated version. Originally it was written in Korean. (http://www.slideshare.net/saltynut/how-do-we-drive-tech-changes ) It describes how do we drive technical changes onto our organizations had used old-fashioned java combinations(Java 1.6+Spring 3.x+MyBatis) and monolithic architecture. Key point is what we need to do to drive changes, and I'll discuss what we did during Phase1 and what we are doing at Phase 2 for architecture, frontend, backend, methodologies/process. Phase1 - Architecture : Frontend / Backend Separation - Frontend : Angular.js, Grunt, Bower - Backend : Java 1.7/Spring4, ORM - Methodology/Process : Scrum, Git Phase2 - Architecture : Micro-Service Architecture(MSA) - Frontend : Content Router, E2E Test - Backend : Polyglot, Multi-Framework - Methodology/Process : Scrum+JIRA, Git Branch Policy, Pair Programming, Code Workshop

This document summarizes Tim Hobson's experiences using Spring Boot to develop QuickBooks Self-Employed. Some key points: - Spring Boot allowed for rapid prototyping and helped establish patterns early in development. The product launched on time with continuous new feature releases. - The lack of XML configuration, auto-configuration features, and starter dependencies significantly improved developer productivity. - Customizations were required for security, batch processing, testing mocks, and DevOps/monitoring but Spring Boot provided capabilities to support these needs. - Overall the experience with Spring Boot was very positive and enabled the QuickBooks Self-Employed product to successfully launch and scale.

A quick overview of application networking and microservice resilience and how a service mesh like Istio.io can help alleviate some of this pain.

Developer's time is the most crucial resource in an enterprise IT organization. Too much time is spent on undifferentiated heavy lifting and in the world of APIs and microservices much of that is spent on non-functional, cross-cutting networking requirements like security, observability, and resilience. As organizations reconcile their DevOps practices into Platform Engineering, tools like Istio help alleviate developer pain. In this talk we dig into what that pain looks like, how much it costs, and how Istio has solved these concerns by examining three real-life use cases. As this space continues to emerge, and innovation has not slowed, we will also discuss the recently announced Istio sidecar-less mode which significantly reduces the hurdles to adopt Istio within Kubernetes or outside Kubernetes.

Service mesh is a powerful pattern for implementing strong zero-trust networking practices, introducing better network observability, and allowing for more fine-grained traffic control. Up until now, the sidecar pattern was used to implement service-mesh capability but as the technology matures, a new pattern has emerged: sidecarless service mesh. Two prominent open-source networking projects, Cilium and Istio, have implemented a sidecar-free approach to service mesh but they both make interesting design decisions and tradeoffs. In this talk we review the architecture of both, focusing on the pros and cons of implementations such as mutual authentication, ingress, and observability.