This document provides an introduction to microservices. It begins by outlining the challenges of monolithic architecture such as long build/release cycles and difficulty scaling. It then introduces microservices as a way to decompose monolithic applications into independently deployable services. Key benefits of microservices include improved agility, scalability, and innovation. The document discusses microservice design principles like communicating over APIs, using the right tools for each service, securing services, and being a good citizen in the ecosystem. It provides examples of how to implement a restaurant microservice using AWS services like API Gateway, Lambda, DynamoDB and containers.
Microservice Architecture | Microservices Tutorial for Beginners | Microservi...Edureka!
( 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
This document provides an introduction to Docker. It discusses why Docker is useful for isolation, being lightweight, simplicity, workflow, and community. It describes the Docker engine, daemon, and CLI. It explains how Docker Hub provides image storage and automated builds. It outlines the Docker installation process and common workflows like finding images, pulling, running, stopping, and removing containers and images. It promotes Docker for building local images and using host volumes.
This is a small introduction to microservices. you can find the differences between microservices and monolithic applications. You will find the pros and cons of microservices. you will also find the challenges (Business/ technical) that you may face while implementing microservices.
Kubernetes is an open-source system for managing containerized applications across multiple hosts. It includes key components like Pods, Services, ReplicationControllers, and a master node for managing the cluster. The master maintains state using etcd and schedules containers on worker nodes, while nodes run the kubelet daemon to manage Pods and their containers. Kubernetes handles tasks like replication, rollouts, and health checking through its API objects.
The document provides an overview of microservices architecture including:
- Definitions and characteristics of microservices such as componentization via services, decentralized governance, and infrastructure automation.
- Common drivers for adopting microservices like agility, safety, and scalability.
- Guidelines for decomposing monolithic applications into microservices based on business capabilities and domain-driven design.
- Discussion of differences between microservices and service-oriented architecture (SOA).
- Ecosystem of tools involved in microservices including development frameworks, APIs, databases, containers, and service meshes.
- Common design patterns and anti-patterns when developing microservices.
This document provides information about Azure DevOps and DevOps practices. It discusses how DevOps brings together people, processes, and technology to automate software delivery and provide continuous value to users. It also outlines some key DevOps technologies like continuous integration, continuous delivery, and continuous monitoring. Additionally, the document shares how Azure DevOps can help teams deliver software faster and more reliably through tools for planning, source control, building, testing, and deploying.
What are Microservices | Microservices Architecture Training | Microservices ...Edureka!
( Microservices Architecture Training: https://www.edureka.co/microservices-architecture-training)
This Edureka's Microservices tutorial on What are Microservices gives you an introduction to microservices and also shows the practical implementation of microservices with a demo.
In this video, you will learn the following:
1.Why Microservices
2.What Is Microservice Architecture
3.Features Of Microservice Architecture
4.Advantages Of Microservice Architecture
5.Companies Using Microservices
6.Hands-On Using SpringBoot
Kubernetes Concepts And Architecture Powerpoint Presentation SlidesSlideTeam
The document provides an overview of Kubernetes concepts and architecture. It begins with an introduction to containers and microservices architecture. It then discusses what Kubernetes is and why organizations should use it. The remainder of the document outlines Kubernetes components, nodes, development processes, networking, and security measures. It provides descriptions and diagrams explaining key aspects of Kubernetes such as architecture, components like Kubelet and Kubectl, node types, and networking models.
The presentation from our online webinar "Design patterns for microservice architecture".
Full video from webinar available here: https://www.youtube.com/watch?v=826aAmG06KM
If you’re a CTO or a Lead Developer and you’re planning to design service-oriented architecture, it’s definitely a webinar tailored to your needs. Adrian Zmenda, our Lead Dev, will explain:
- when microservice architecture is a safe bet and what are some good alternatives
- what are the pros and cons of the most popular design patterns (API Gateway, Backend for Frontend and more)
- how to ensure that the communication between services is done right and what to do in case of connection issues
- why we’ve decided to use a monorepo (monolithic repository)
- what we’ve learned from using the remote procedure call framework gRPC
- how to monitor the efficiency of individual services and whole SOA-based systems.
A introduction to Microservices Architecture: definition, characterstics, framworks, success stories. It contains a demo about implementation of microservices with Spring Boot, Spring cloud an Eureka.
Microservices are an architectural style that structures an application as a collection of small, independent services that communicate with each other. Each service runs a unique process and focuses on doing a small job, such as user authentication or shopping cart functionality. The advantages of microservices include improved scalability, maintainability, and ability to upgrade parts of the system independently. However, adopting microservices also introduces additional operational complexity and communication overhead between services.
This is the video capture of the meetup described at https://www.meetup.com/lifemichael/events/287981390/ This video includes the two talks the meetup included. The first one is an introductory talk for the topic. The second one covers the SAGA design pattern.
This document provides an overview of Kubernetes including:
1) Kubernetes is an open-source platform for automating deployment, scaling, and operations of containerized applications. It provides container-centric infrastructure and allows for quickly deploying and scaling applications.
2) The main components of Kubernetes include Pods (groups of containers), Services (abstract access to pods), ReplicationControllers (maintain pod replicas), and a master node running key components like etcd, API server, scheduler, and controller manager.
3) The document demonstrates getting started with Kubernetes by enabling the master on one node and a worker on another node, then deploying and exposing a sample nginx application across the cluster.
This presentation is conducted on 14th Sept in Limerick DotNet User Group.
(https://www.meetup.com/preview/Limerick-DotNet/events/xskpdnywmbsb)
SlideShare Url: https://www.slideshare.net/lalitkale/introduction-to-microservices-80583928
In this presentation, new architectural style - Microservices and it's emergence is discussed. We will also briefly touch base on what are not microservices, Conway's law and organization design, Principles of microservices and service discovery mechanism and why it is necessary for microservices implementation.
About Speaker:
Lalit is a senior developer, software architect and consultant with more than 12 yrsof .NET experience. He loves to work with C# .NET and Azure platform services like App Services, Virtual Machines, Cortana, and Container Services. He is also the author of 'Building Microservices with .NET Core' (https://www.packtpub.com/web-development/building-microservices-net-core) book.
To know more and connect with Lalit, you can visit his LinkedIn profile below. https://www.linkedin.com/in/lalitkale/
This presentation will be useful for software architects/Managers, senior developers.
Do share your feedback in comments.
The introduction covers the following
1. What are Microservices and why should be use this paradigm?
2. 12 factor apps and how Microservices make it easier to create them
3. Characteristics of Microservices
Note: Please download the slides to view animations.
Understanding MicroSERVICE Architecture with Java & Spring BootKashif Ali Siddiqui
This is a deep journey into the realm of "microservice architecture", and in that I will try to cover each inch of it, but with a fixed tech stack of Java with Spring Cloud. Hence in the end, you will be get know each and every aspect of this distributed design, and will develop an understanding of each and every concern regarding distributed system construct.
This document provides an introduction to Docker and discusses how it helps address challenges in the modern IT landscape. Some key points:
- Applications are increasingly being broken up into microservices and deployed across multiple servers and environments, making portability and scalability important.
- Docker containers help address these issues by allowing applications to run reliably across different infrastructures through package dependencies and resources together. This improves portability.
- Docker provides a platform for building, shipping and running applications. It helps bridge the needs of developers who want fast innovation and operations teams who need security and control.
This document provides an overview of microservices architecture, including concepts, characteristics, infrastructure patterns, and software design patterns relevant to microservices. It discusses when microservices should be used versus monolithic architectures, considerations for sizing microservices, and examples of pioneers in microservices implementation like Netflix and Spotify. The document also covers domain-driven design concepts like bounded context that are useful for decomposing monolithic applications into microservices.
Introduction to Microservices Patterns. In these slides we explore microservices vs monolith apis. We try to identify the challenges of moving to microservices ecosystem and try to analyze possible solutions for data consistency, inter-communication, event driven and distributed transactions.
Fred George describes his personal journey discovering microservice architecture over 15 years working on large software projects. He details how his projects evolved from monolithic 1 million line applications to small, independent services. This allowed for improved agility, with services being short-lived and able to deploy several times a day. George also discusses challenges faced and lessons learned around loosely coupling services, managing data across services, and establishing practices for a "living software" system with continuous deployment of services.
Principles of microservices XP Days UkraineSam Newman
The document outlines principles of microservices, including modeling services around business domains, having a culture of automation, hiding implementation details, decentralizing systems, isolating failures, deploying independently, making systems highly observable, and other principles. The presentation provides examples and discusses strategic goals and architectural practices for designing fine-grained microservice systems.
Divide y Vencerás: introducción a los MicroserviciosThoughtworks
Actualmente está muy de moda los términos SOA, descentralización de servicios, microservicios... pero, ¿qué significan realmente?
En esta charla intentaremos aclarar estas dudas además de explicar como podemos utilizar los nuevos paradigmas y diseños arquitectónicos para crear aplicaciones sencillas de construir, escalables y que sigan cumpliendo los requerimientos del negocio.
Esta charla se presentó por primera vez en el evento ComparTI/Tech Stage en las oficinas de Thoughtworks Quito en Enero de 2015. http://info.thoughtworks.com/ComparTI-Quito-Enero_Registration-Page.html
How Spotify Builds Products (Organization. Architecture, Autonomy, Accountabi...Kevin Goldsmith
This was an extended version of the talk that I gave at InfoShare 2016 in GDansk. This version of the talk was presented at ao.com and Think Money in Manchester UK in May 2016. This is a remix of several earlier talks and some new content to tie Spotify's autonomy and continuous improvement culture to it's data-driven product development approach to show the complete picture. As usual, I tend to talk to slides instead of putting a lot of the content into the slides themselves, so sorry if these don't have all the info.
Why does Spotify use a microservices architecture? What are the benefits and challenges we've encountered? How does our organizational model support our architecture?
Video of the talk is posted on YouTube: https://youtu.be/7LGPeBgNFuU
This document provides an overview of architecting microservices using .NET. It discusses why microservices are used, common architecture patterns, and implementation considerations. Key points include:
- Independent, loosely coupled services that are fault tolerant and easy to scale are goals of a microservices architecture.
- Communication between services should be kept simple, using either synchronous HTTP or asynchronous messaging. Synchronous calls can lead to temporal coupling so circuit breakers and failure handling are important.
- Domain-driven design principles like bounded contexts and separating queries from commands (CQRS) can help define appropriate service boundaries and responsibilities.
- Event sourcing avoids shared state and two-phase commits by persisting a sequence of events rather than
Introduction to Microservices by Jim Tran, Principal Solutions Architect, AWSAmazon Web Services
This document discusses architecting microservices on AWS. It begins by outlining challenges with monolithic software architectures like long build/test/release cycles and difficulty scaling. It then introduces microservices as a way to decompose applications into independently deployable services. Key principles for microservices include having services communicate over APIs, using the right data store for each service's needs, securing services through defense-in-depth, and collaborating as good ecosystem citizens. The document provides examples of implementing a sample restaurant microservice on AWS using Lambda, API Gateway, DynamoDB, and other services. It emphasizes that microservices require not just technical changes but organizational transformation as well.
Microservices architectures are changing the way that organizations build their applications and infrastructure. Companies can now achieve new levels of scale and efficiency by disaggregating their large, monolithic applications into small, independent “micro services”, each of which perform different functions. In this session, we’ll introduce the concept of microservices, help you evaluate whether your organization is ready for microservices, and discuss methods for implementing these architectures.
This document provides an overview of a presentation on microservices. The presentation includes sections on evolving from monolithic architectures to microservices, principles of microservices like loose coupling and single responsibility, and an example of building a simple microservice. The document lists the expected sections of the presentation.
Microservices architectures are changing the way that organizations build their applications and infrastructure. Companies can now achieve new levels of scale and efficiency by disaggregating their large, monolithic applications into small, independent “micro services”, each of which perform different functions. In this session, we’ll introduce the concept of microservices, help you evaluate whether your organization is ready for microservices, and discuss methods for implementing these architectures. We’ll also cover topics such as using API gateways, enabling self-service infrastructure provisioning, and ways to manage your microservices.
Microservices on AWS: Divide & Conquer for Agility and ScalabilityAmazon Web Services
To tackle complexity and change, AWS customers are increasingly evolving their architectures from monoliths towards microservices, and benefiting from increased agility, simplified scalability, resiliency, and faster deployments. However, microservices also introduce new technical challenges. In this session, we'll provide an introduction and overview of the benefits and challenges of micrososervices, and share best practices for architecting and deploying microservices on AWS.
Microservices on AWS: Divide & Conquer for Agility and ScalabilityAmazon Web Services
To tackle complexity and change, AWS customers are increasingly evolving their architectures from monoliths towards microservices, and benefiting from increased agility, simplified scalability, resiliency, and faster deployments. However, microservices also introduce new technical challenges. In this session, we'll provide an introduction and overview of the benefits and challenges of micrososervices, and share best practices for architecting and deploying microservices on AWS.
Enterprise summit – architecting microservices on aws final v2Amazon Web Services
To tackle complexity and change, AWS customers are increasingly evolving their architectures from monoliths towards microservices, and benefiting from increased agility, simplified scalability, resiliency, and faster deployments. However, microservices also introduce new technical challenges. In this session, we'll provide an introduction and overview of the benefits and challenges of micrososervices, and share best practices for architecting and deploying microservices on AWS.
Divide and conquer for agility and scalability: An introduction to MicroservicesAmazon Web Services
"
To tackle complexity and change, AWS customers are increasingly evolving their architectures from monoliths towards microservices, and benefiting from increased agility, simplified scalability, resiliency, and faster deployments. However, microservices also introduce new technical challenges. In this session, we'll provide an introduction and overview of the benefits and challenges of micrososervices, and share best practices for architecting and deploying microservices on AWS."
Container Days: Architecting Modern Apps on AWSTara Walker
This document provides an overview of architecting modern applications on AWS using microservices. It discusses evolving from monolithic architectures to microservices by breaking applications into smaller, independent services. Key principles of microservices architectures are described, including services relying only on public APIs, using the right tools for the job, securing services, being a good citizen in the ecosystem through monitoring and documentation, and addressing organizational transformation. Specific AWS services for building microservices are also covered, such as API Gateway, Lambda, EC2, ECS, DynamoDB, and others. The document aims to help architects modernize applications on AWS.
Start Up Austin 2017: If How and When to Adopt MicroservicesAmazon Web Services
Monolith architectures can work well for early-stage startups but begin to struggle as applications and companies grow larger. Microservices architectures break applications into smaller, independently deployable services that communicate over well-defined APIs. This improves scalability, innovation, and agility by allowing teams to work independently and update services without disrupting others. When adopting microservices, services should only rely on each other's public APIs, use the right data store for each service's needs, implement security best practices, and cooperate as good ecosystem citizens.
Microservices and serverless for MegaStartups - DLD TLV 2017Boaz Ziniman
Boaz Ziniman, a technical evangelist at AWS, presented on microservices and serverless architectures for mega startups. He discussed how monolithic architectures can limit agility and discussed how microservices help address these issues by decomposing applications into independently deployable services. He then explained how serverless computing removes the need to manage servers by allowing developers to run code without provisioning or managing servers. Examples of serverless offerings from AWS like AWS Lambda were provided. Common use cases for microservices and serverless architectures like web applications, backends, and data processing were also outlined.
Microsoft Ignite 2018 BRK3192 Container DevOps on AzureJessica Deen
This document provides an overview of DevOps concepts and tools. It discusses containers and container orchestration with Kubernetes. It also mentions Azure DevOps and Azure Kubernetes Service (AKS) as tools that can help with DevOps practices like continuous integration/delivery (CI/CD). Helm charts are presented as a way to define and manage complex Kubernetes applications and services. Some best practices for Kubernetes are also listed.
Overview of azure microservices and the impact on integrationBizTalk360
On the back of Integrate 2014, Sam Vanhoutte will discuss view on some of the implications of the announcements made at the conference and talk about how this might affect the future for integration professionals
Codemotion DevCast: App Modernization in the CloudLorenzo Barbieri
This document discusses app modernization and how moving applications to the cloud on Azure can provide benefits. It outlines the app modernization continuum from refactoring existing applications to rebuilding new serverless applications. Key techniques discussed are containers, microservices, and serverless computing. Containers can help with modernization by allowing existing applications to lift and shift to containers for improved scalability. Microservices and serverless options further improve agility, productivity and operational efficiency. The document emphasizes that Azure supports a hybrid cloud approach and provides services for infrastructure, platforms and serverless applications.
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.
Introducing to serverless computing and AWS lambda - Israel Clouds MeetupBoaz Ziniman
Serverless computing allows you to build and run applications without the need for provisioning or managing servers. With serverless computing, you can build web, mobile, and IoT backends; run stream processing or big data workloads; run chatbots, and more.
Come costruire servizi di Forecasting sfruttando algoritmi di ML e deep learn...Amazon Web Services
Il Forecasting è un processo importante per tantissime aziende e viene utilizzato in vari ambiti per cercare di prevedere in modo accurato la crescita e distribuzione di un prodotto, l’utilizzo delle risorse necessarie nelle linee produttive, presentazioni finanziarie e tanto altro. Amazon utilizza delle tecniche avanzate di forecasting, in parte questi servizi sono stati messi a disposizione di tutti i clienti AWS.
In questa sessione illustreremo come pre-processare i dati che contengono una componente temporale e successivamente utilizzare un algoritmo che a partire dal tipo di dato analizzato produce un forecasting accurato.
Big Data per le Startup: come creare applicazioni Big Data in modalità Server...Amazon Web Services
La varietà e la quantità di dati che si crea ogni giorno accelera sempre più velocemente e rappresenta una opportunità irripetibile per innovare e creare nuove startup.
Tuttavia gestire grandi quantità di dati può apparire complesso: creare cluster Big Data su larga scala sembra essere un investimento accessibile solo ad aziende consolidate. Ma l’elasticità del Cloud e, in particolare, i servizi Serverless ci permettono di rompere questi limiti.
Vediamo quindi come è possibile sviluppare applicazioni Big Data rapidamente, senza preoccuparci dell’infrastruttura, ma dedicando tutte le risorse allo sviluppo delle nostre le nostre idee per creare prodotti innovativi.
Ora puoi utilizzare Amazon Elastic Kubernetes Service (EKS) per eseguire pod Kubernetes su AWS Fargate, il motore di elaborazione serverless creato per container su AWS. Questo rende più semplice che mai costruire ed eseguire le tue applicazioni Kubernetes nel cloud AWS.In questa sessione presenteremo le caratteristiche principali del servizio e come distribuire la tua applicazione in pochi passaggi
Vent'anni fa Amazon ha attraversato una trasformazione radicale con l'obiettivo di aumentare il ritmo dell'innovazione. In questo periodo abbiamo imparato come cambiare il nostro approccio allo sviluppo delle applicazioni ci ha permesso di aumentare notevolmente l'agilità, la velocità di rilascio e, in definitiva, ci ha consentito di creare applicazioni più affidabili e scalabili. In questa sessione illustreremo come definiamo le applicazioni moderne e come la creazione di app moderne influisce non solo sull'architettura dell'applicazione, ma sulla struttura organizzativa, sulle pipeline di rilascio dello sviluppo e persino sul modello operativo. Descriveremo anche approcci comuni alla modernizzazione, compreso l'approccio utilizzato dalla stessa Amazon.com.
Come spendere fino al 90% in meno con i container e le istanze spot Amazon Web Services
L’utilizzo dei container è in continua crescita.
Se correttamente disegnate, le applicazioni basate su Container sono molto spesso stateless e flessibili.
I servizi AWS ECS, EKS e Kubernetes su EC2 possono sfruttare le istanze Spot, portando ad un risparmio medio del 70% rispetto alle istanze On Demand. In questa sessione scopriremo insieme quali sono le caratteristiche delle istanze Spot e come possono essere utilizzate facilmente su AWS. Impareremo inoltre come Spreaker sfrutta le istanze spot per eseguire applicazioni di diverso tipo, in produzione, ad una frazione del costo on-demand!
In recent months, many customers have been asking us the question – how to monetise Open APIs, simplify Fintech integrations and accelerate adoption of various Open Banking business models. Therefore, AWS and FinConecta would like to invite you to Open Finance marketplace presentation on October 20th.
Event Agenda :
Open banking so far (short recap)
• PSD2, OB UK, OB Australia, OB LATAM, OB Israel
Intro to Open Finance marketplace
• Scope
• Features
• Tech overview and Demo
The role of the Cloud
The Future of APIs
• Complying with regulation
• Monetizing data / APIs
• Business models
• Time to market
One platform for all: a Strategic approach
Q&A
Rendi unica l’offerta della tua startup sul mercato con i servizi Machine Lea...Amazon Web Services
Per creare valore e costruire una propria offerta differenziante e riconoscibile, le startup di successo sanno come combinare tecnologie consolidate con componenti innovativi creati ad hoc.
AWS fornisce servizi pronti all'utilizzo e, allo stesso tempo, permette di personalizzare e creare gli elementi differenzianti della propria offerta.
Concentrandoci sulle tecnologie di Machine Learning, vedremo come selezionare i servizi di intelligenza artificiale offerti da AWS e, anche attraverso una demo, come costruire modelli di Machine Learning personalizzati utilizzando SageMaker Studio.
OpsWorks Configuration Management: automatizza la gestione e i deployment del...Amazon Web Services
Con l'approccio tradizionale al mondo IT per molti anni è stato difficile implementare tecniche di DevOps, che finora spesso hanno previsto attività manuali portando di tanto in tanto a dei downtime degli applicativi interrompendo l'operatività dell'utente. Con l'avvento del cloud, le tecniche di DevOps sono ormai a portata di tutti a basso costo per qualsiasi genere di workload, garantendo maggiore affidabilità del sistema e risultando in dei significativi miglioramenti della business continuity.
AWS mette a disposizione AWS OpsWork come strumento di Configuration Management che mira ad automatizzare e semplificare la gestione e i deployment delle istanze EC2 per mezzo di workload Chef e Puppet.
Scopri come sfruttare AWS OpsWork a garanzia e affidabilità del tuo applicativo installato su Instanze EC2.
Microsoft Active Directory su AWS per supportare i tuoi Windows WorkloadsAmazon Web Services
Vuoi conoscere le opzioni per eseguire Microsoft Active Directory su AWS? Quando si spostano carichi di lavoro Microsoft in AWS, è importante considerare come distribuire Microsoft Active Directory per supportare la gestione, l'autenticazione e l'autorizzazione dei criteri di gruppo. In questa sessione, discuteremo le opzioni per la distribuzione di Microsoft Active Directory su AWS, incluso AWS Directory Service per Microsoft Active Directory e la distribuzione di Active Directory su Windows su Amazon Elastic Compute Cloud (Amazon EC2). Trattiamo argomenti quali l'integrazione del tuo ambiente Microsoft Active Directory locale nel cloud e l'utilizzo di applicazioni SaaS, come Office 365, con AWS Single Sign-On.
Dal riconoscimento facciale al riconoscimento di frodi o difetti di fabbricazione, l'analisi di immagini e video che sfruttano tecniche di intelligenza artificiale, si stanno evolvendo e raffinando a ritmi elevati. In questo webinar esploreremo le possibilità messe a disposizione dai servizi AWS per applicare lo stato dell'arte delle tecniche di computer vision a scenari reali.
Amazon Web Services e VMware organizzano un evento virtuale gratuito il prossimo mercoledì 14 Ottobre dalle 12:00 alle 13:00 dedicato a VMware Cloud ™ on AWS, il servizio on demand che consente di eseguire applicazioni in ambienti cloud basati su VMware vSphere® e di accedere ad una vasta gamma di servizi AWS, sfruttando a pieno le potenzialità del cloud AWS e tutelando gli investimenti VMware esistenti.
Molte organizzazioni sfruttano i vantaggi del cloud migrando i propri carichi di lavoro Oracle e assicurandosi notevoli vantaggi in termini di agilità ed efficienza dei costi.
La migrazione di questi carichi di lavoro, può creare complessità durante la modernizzazione e il refactoring delle applicazioni e a questo si possono aggiungere rischi di prestazione che possono essere introdotti quando si spostano le applicazioni dai data center locali.
Crea la tua prima serverless ledger-based app con QLDB e NodeJSAmazon Web Services
Molte aziende oggi, costruiscono applicazioni con funzionalità di tipo ledger ad esempio per verificare lo storico di accrediti o addebiti nelle transazioni bancarie o ancora per tenere traccia del flusso supply chain dei propri prodotti.
Alla base di queste soluzioni ci sono i database ledger che permettono di avere un log delle transazioni trasparente, immutabile e crittograficamente verificabile, ma sono strumenti complessi e onerosi da gestire.
Amazon QLDB elimina la necessità di costruire sistemi personalizzati e complessi fornendo un database ledger serverless completamente gestito.
In questa sessione scopriremo come realizzare un'applicazione serverless completa che utilizzi le funzionalità di QLDB.
Con l’ascesa delle architetture di microservizi e delle ricche applicazioni mobili e Web, le API sono più importanti che mai per offrire agli utenti finali una user experience eccezionale. In questa sessione impareremo come affrontare le moderne sfide di progettazione delle API con GraphQL, un linguaggio di query API open source utilizzato da Facebook, Amazon e altro e come utilizzare AWS AppSync, un servizio GraphQL serverless gestito su AWS. Approfondiremo diversi scenari, comprendendo come AppSync può aiutare a risolvere questi casi d’uso creando API moderne con funzionalità di aggiornamento dati in tempo reale e offline.
Inoltre, impareremo come Sky Italia utilizza AWS AppSync per fornire aggiornamenti sportivi in tempo reale agli utenti del proprio portale web.
Database Oracle e VMware Cloud™ on AWS: i miti da sfatareAmazon Web Services
Molte organizzazioni sfruttano i vantaggi del cloud migrando i propri carichi di lavoro Oracle e assicurandosi notevoli vantaggi in termini di agilità ed efficienza dei costi.
La migrazione di questi carichi di lavoro, può creare complessità durante la modernizzazione e il refactoring delle applicazioni e a questo si possono aggiungere rischi di prestazione che possono essere introdotti quando si spostano le applicazioni dai data center locali.
In queste slide, gli esperti AWS e VMware presentano semplici e pratici accorgimenti per facilitare e semplificare la migrazione dei carichi di lavoro Oracle accelerando la trasformazione verso il cloud, approfondiranno l’architettura e dimostreranno come sfruttare a pieno le potenzialità di VMware Cloud ™ on AWS.
1) The document discusses building a minimum viable product (MVP) using Amazon Web Services (AWS).
2) It provides an example of an MVP for an omni-channel messenger platform that was built from 2017 to connect ecommerce stores to customers via web chat, Facebook Messenger, WhatsApp, and other channels.
3) The founder discusses how they started with an MVP in 2017 with 200 ecommerce stores in Hong Kong and Taiwan, and have since expanded to over 5000 clients across Southeast Asia using AWS for scaling.
This document discusses pitch decks and fundraising materials. It explains that venture capitalists will typically spend only 3 minutes and 44 seconds reviewing a pitch deck. Therefore, the deck needs to tell a compelling story to grab their attention. It also provides tips on tailoring different types of decks for different purposes, such as creating a concise 1-2 page teaser, a presentation deck for pitching in-person, and a more detailed read-only or fundraising deck. The document stresses the importance of including key information like the problem, solution, product, traction, market size, plans, team, and ask.
This document discusses building serverless web applications using AWS services like API Gateway, Lambda, DynamoDB, S3 and Amplify. It provides an overview of each service and how they can work together to create a scalable, secure and cost-effective serverless application stack without having to manage servers or infrastructure. Key services covered include API Gateway for hosting APIs, Lambda for backend logic, DynamoDB for database needs, S3 for static content, and Amplify for frontend hosting and continuous deployment.
This document provides tips for fundraising from startup founders Roland Yau and Sze Lok Chan. It discusses generating competition to create urgency for investors, fundraising in parallel rather than sequentially, having a clear fundraising narrative focused on what you do and why it's compelling, and prioritizing relationships with people over firms. It also notes how the pandemic has changed fundraising, with examples of deals done virtually during this time. The tips emphasize being fully prepared before fundraising and cultivating connections with investors in advance.
AWS_HK_StartupDay_Building Interactive websites while automating for efficien...Amazon Web Services
This document discusses Amazon's machine learning services for building conversational interfaces and extracting insights from unstructured text and audio. It describes Amazon Lex for creating chatbots, Amazon Comprehend for natural language processing tasks like entity extraction and sentiment analysis, and how they can be used together for applications like intelligent call centers and content analysis. Pre-trained APIs simplify adding machine learning to apps without requiring ML expertise.
Amazon Elastic Container Service (Amazon ECS) è un servizio di gestione dei container altamente scalabile, che semplifica la gestione dei contenitori Docker attraverso un layer di orchestrazione per il controllo del deployment e del relativo lifecycle. In questa sessione presenteremo le principali caratteristiche del servizio, le architetture di riferimento per i differenti carichi di lavoro e i semplici passi necessari per poter velocemente migrare uno o più dei tuo container.
Understanding Insider Security Threats: Types, Examples, Effects, and Mitigat...Bert Blevins
Today’s digitally connected world presents a wide range of security challenges for enterprises. Insider security threats are particularly noteworthy because they have the potential to cause significant harm. Unlike external threats, insider risks originate from within the company, making them more subtle and challenging to identify. This blog aims to provide a comprehensive understanding of insider security threats, including their types, examples, effects, and mitigation techniques.
RPA In Healthcare Benefits, Use Case, Trend And Challenges 2024.pptxSynapseIndia
Your comprehensive guide to RPA in healthcare for 2024. Explore the benefits, use cases, and emerging trends of robotic process automation. Understand the challenges and prepare for the future of healthcare automation
Quality Patents: Patents That Stand the Test of TimeAurora Consulting
Is your patent a vanity piece of paper for your office wall? Or is it a reliable, defendable, assertable, property right? The difference is often quality.
Is your patent simply a transactional cost and a large pile of legal bills for your startup? Or is it a leverageable asset worthy of attracting precious investment dollars, worth its cost in multiples of valuation? The difference is often quality.
Is your patent application only good enough to get through the examination process? Or has it been crafted to stand the tests of time and varied audiences if you later need to assert that document against an infringer, find yourself litigating with it in an Article 3 Court at the hands of a judge and jury, God forbid, end up having to defend its validity at the PTAB, or even needing to use it to block pirated imports at the International Trade Commission? The difference is often quality.
Quality will be our focus for a good chunk of the remainder of this season. What goes into a quality patent, and where possible, how do you get it without breaking the bank?
** Episode Overview **
In this first episode of our quality series, Kristen Hansen and the panel discuss:
⦿ What do we mean when we say patent quality?
⦿ Why is patent quality important?
⦿ How to balance quality and budget
⦿ The importance of searching, continuations, and draftsperson domain expertise
⦿ Very practical tips, tricks, examples, and Kristen’s Musts for drafting quality applications
https://www.aurorapatents.com/patently-strategic-podcast.html
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-InTrustArc
Six months into 2024, and it is clear the privacy ecosystem takes no days off!! Regulators continue to implement and enforce new regulations, businesses strive to meet requirements, and technology advances like AI have privacy professionals scratching their heads about managing risk.
What can we learn about the first six months of data privacy trends and events in 2024? How should this inform your privacy program management for the rest of the year?
Join TrustArc, Goodwin, and Snyk privacy experts as they discuss the changes we’ve seen in the first half of 2024 and gain insight into the concrete, actionable steps you can take to up-level your privacy program in the second half of the year.
This webinar will review:
- Key changes to privacy regulations in 2024
- Key themes in privacy and data governance in 2024
- How to maximize your privacy program in the second half of 2024
Paradigm Shifts in User Modeling: A Journey from Historical Foundations to Em...Erasmo Purificato
Slide of the tutorial entitled "Paradigm Shifts in User Modeling: A Journey from Historical Foundations to Emerging Trends" held at UMAP'24: 32nd ACM Conference on User Modeling, Adaptation and Personalization (July 1, 2024 | Cagliari, Italy)
Transcript: Details of description part II: Describing images in practice - T...BookNet Canada
This presentation explores the practical application of image description techniques. Familiar guidelines will be demonstrated in practice, and descriptions will be developed “live”! If you have learned a lot about the theory of image description techniques but want to feel more confident putting them into practice, this is the presentation for you. There will be useful, actionable information for everyone, whether you are working with authors, colleagues, alone, or leveraging AI as a collaborator.
Link to presentation recording and slides: https://bnctechforum.ca/sessions/details-of-description-part-ii-describing-images-in-practice/
Presented by BookNet Canada on June 25, 2024, with support from the Department of Canadian Heritage.
BT & Neo4j: Knowledge Graphs for Critical Enterprise Systems.pptx.pdfNeo4j
Presented at Gartner Data & Analytics, London Maty 2024. BT Group has used the Neo4j Graph Database to enable impressive digital transformation programs over the last 6 years. By re-imagining their operational support systems to adopt self-serve and data lead principles they have substantially reduced the number of applications and complexity of their operations. The result has been a substantial reduction in risk and costs while improving time to value, innovation, and process automation. Join this session to hear their story, the lessons they learned along the way and how their future innovation plans include the exploration of uses of EKG + Generative AI.
Choose our Linux Web Hosting for a seamless and successful online presencerajancomputerfbd
Our Linux Web Hosting plans offer unbeatable performance, security, and scalability, ensuring your website runs smoothly and efficiently.
Visit- https://onliveserver.com/linux-web-hosting/
Sustainability requires ingenuity and stewardship. Did you know Pigging Solutions pigging systems help you achieve your sustainable manufacturing goals AND provide rapid return on investment.
How? Our systems recover over 99% of product in transfer piping. Recovering trapped product from transfer lines that would otherwise become flush-waste, means you can increase batch yields and eliminate flush waste. From raw materials to finished product, if you can pump it, we can pig it.
Kief Morris rethinks the infrastructure code delivery lifecycle, advocating for a shift towards composable infrastructure systems. We should shift to designing around deployable components rather than code modules, use more useful levels of abstraction, and drive design and deployment from applications rather than bottom-up, monolithic architecture and delivery.
The DealBook is our annual overview of the Ukrainian tech investment industry. This edition comprehensively covers the full year 2023 and the first deals of 2024.
How Social Media Hackers Help You to See Your Wife's Message.pdfHackersList
In the modern digital era, social media platforms have become integral to our daily lives. These platforms, including Facebook, Instagram, WhatsApp, and Snapchat, offer countless ways to connect, share, and communicate.
Support en anglais diffusé lors de l'événement 100% IA organisé dans les locaux parisiens d'Iguane Solutions, le mardi 2 juillet 2024 :
- Présentation de notre plateforme IA plug and play : ses fonctionnalités avancées, telles que son interface utilisateur intuitive, son copilot puissant et des outils de monitoring performants.
- REX client : Cyril Janssens, CTO d’ easybourse, partage son expérience d’utilisation de notre plateforme IA plug & play.
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...Chris Swan
Have you noticed the OpenSSF Scorecard badges on the official Dart and Flutter repos? It's Google's way of showing that they care about security. Practices such as pinning dependencies, branch protection, required reviews, continuous integration tests etc. are measured to provide a score and accompanying badge.
You can do the same for your projects, and this presentation will show you how, with an emphasis on the unique challenges that come up when working with Dart and Flutter.
The session will provide a walkthrough of the steps involved in securing a first repository, and then what it takes to repeat that process across an organization with multiple repos. It will also look at the ongoing maintenance involved once scorecards have been implemented, and how aspects of that maintenance can be better automated to minimize toil.
11. Challenges with monolithic software
Long
Build/Test/Release
Cycles
(who broke the build?)
Operations
is a nightmare
(module X is failing,
who’s the owner?)
Difficult to
scale
New releases
take months
Long time to add
new features
Architecture is
hard to maintain
and evolve
Lack of innovation
Frustrated customers
Lack of agility
12. Challenges with monolithic software
Long
Build/Test/Release
Cycles
(who broke the build?)
Operations
is a nightmare
(module X is failing,
who’s the owner?)
Difficult to
scale
New releases
take months
Long time to add
new features
Architecture is
hard to maintain
and evolve
Lack of innovation
Frustrated customers
Lack of agility
13. Challenges with monolithic software
Long
Build/Test/Release
Cycles
(who broke the build?)
Operations
is a nightmare
(module X is failing,
who’s the owner?)
Difficult to
scale
New releases
take months
Long time to add
new features
Architecture is
hard to maintain
and evolve
Lack of innovation
Frustrated customers
Lack of agility
14. “20080219BonMorningDSC_0022B” by Sunphol Sorakul . No alterations other than cropping. https://www.flickr.com/photos/83424882@N00/3483881705/
Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
15. Monolith development lifecycle
releasetestbuild
delivery pipeline
app
(aka the“monolith”)developers
Photo by Sage Ross. No alterations other than cropping. https://www.flickr.com/photos/ragesoss/2931770125/
Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
19. Evolving towards microservices
“IMG_1760” by Robert Couse-Baker. No alterations other than cropping. https://www.flickr.com/photos/29233640@N07/14859431605/
Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
20. “IMG_1760” by Robert Couse-Baker. No alterations other than cropping. https://www.flickr.com/photos/29233640@N07/14859431605/
Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
24. Services communicate with
each other over the
network
“service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Adrian Cockcroft (former Cloud Architect at Netflix,
now Technology Fellow at Battery Ventures)
25. “service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Adrian Cockcroft (former Cloud Architect at Netflix,
now Technology Fellow at Battery Ventures)
You can update the services
independently; updating
one service doesn’t require
changing any other services.
26. “service-oriented
architecture
composed of
loosely coupled
elements
that have
bounded contexts”
Adrian Cockcroft (former Cloud Architect at Netflix,
now Technology Fellow at Battery Ventures)
Self-contained; you can
update the code without
knowing anything about the
internals of other
microservices
27. “Do one thing, and do it well”
“Swiss Army” by by Jim Pennucci. No alterations other than cropping. https://www.flickr.com/photos/pennuja/5363518281/
Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
28. “Tools” by Tony Walmsley: No alterations other than cropping. https://www.flickr.com/photos/twalmsley/6825340663/
Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
“Do one thing, and do it well”
38. = 50 million deployments a year
Thousands of teams
× Microservice architecture
× Continuous delivery
× Multiple environments
(5708 per hour, or every 0.63 second)
43. Principle 1
Micro-services only rely
on each other’s public API
“Contracts” by NobMouse. No alterations other than cropping.
https://www.flickr.com/photos/nobmouse/4052848608/
Image used with permissions under Creative Commons license 2.0, Attribution Generic
License (https://creativecommons.org/licenses/by/2.0/)
44. Micro-service A Micro-service B
public API public API
Principle 1: Microservices only rely on each other’s public API
DynamoDB
45. Micro-service A Micro-service B
public API public API
Principle 1: Microservices only rely on each other’s public API
(Hide Your Data)
DynamoDB
46. Micro-service A Micro-service B
public API public API
Principle 1: Microservices only rely on each other’s public API
(Hide Your Data)
Nope!
DynamoDB
47. Micro-service A Micro-service B
public API public API
Principle 1: Microservices only rely on each other’s public API
(Hide Your Data)
DynamoDB
48. Micro-service A
public API
Principle 1: Microservices only rely on each other’s public API
(Evolve API in backward-compatible way…and
document!)
storeRestaurant (id, name, cuisine)
Version 1.0.0
49. Micro-service A
public API
Principle 1: Microservices only rely on each other’s public API
(Evolve API in backward-compatible way…and
document!)
storeRestaurant (id, name, cuisine)
Version 1.0.0
storeRestaurant (id, name, cuisine)
storeRestaurant (id, name,
arbitrary_metadata)
addReview (restaurantId, rating, comments)
Version 1.1.0
50. Micro-service A
public API
Principle 1: Microservices only rely on each other’s public API
(Evolve API in backward-compatible way…and
document!)
storeRestaurant (id, name, cuisine)
Version 1.0.0
storeRestaurant (id, name, cuisine)
storeRestaurant (id, name,
arbitrary_metadata)
addReview (restaurantId, rating, comments)
Version 1.1.0
storeRestaurant (id, name,
arbitrary_metadata)
addReview (restaurantId, rating, comments)
Version 2.0.0
51. Principle 2
Use the right tool for the
job
“Tools #2” by Juan Pablo Olmo. No alterations other than cropping.
https://www.flickr.com/photos/juanpol/1562101472/
Image used with permissions under Creative Commons license 2.0, Attribution Generic
License (https://creativecommons.org/licenses/by/2.0/)
52. Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
Micro-service A Micro-service B
public API public API
DynamoDB
53. Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
Micro-service A Micro-service B
public API public API
DynamoDB
Amazon
Elasticsearch
Service
54. Principle 2: Use the right tool for the job
(Embrace polyglot persistence)
Micro-service A Micro-service B
public API public API
Amazon
Elasticsearch
Service
RDS
Aurora
55. Principle 2: Use the right tool for the job
(Embrace polyglot programming frameworks)
Micro-service A Micro-service B
public API public API
Amazon
Elasticsearch
Service
RDS
Aurora
56. Principle 2: Use the right tool for the job
(Embrace polyglot programming frameworks)
Micro-service A Micro-service B
public API public API
Amazon
Elasticsearch
Service
RDS
Aurora
69. • Prototype in less than 2 months
• Deployment time: hours minutes
• Each team can now develop its
respective applications
independently
Coursera
13 million users from 190 countries
1,000 courses from 119 institutions
78. Lambda
automatically
scales
Upload your code
(Java, JavaScript,
Python)
Pay for only the
compute time
you use
(sub-second
metering)
Set up your code to
trigger from other AWS
services, webservice
calls, or app activity
81. Create a unified
API frontend for
multiple
micro-services
Authenticate and
authorize
requests
82. Create a unified
API frontend for
multiple
micro-services
Authenticate and
authorize
requests
Handles DDoS
protection and
API throttling
83. Create a unified
API frontend for
multiple
micro-services
…as well as
monitoring,
logging, rollbacks,
client SDK
generation…
Authenticate and
authorize
requests
Handles DDoS
protection and
API throttling
92. Highly Scalable
• Inherently scalable
Secure
• API Gateway acts as “front door”
• Can add authN/authZ; or throttle API if needed
• S3 bucket policies
• IAM Roles for Lambda invocations
Cost-efficient
• Only pay for actual microservice usage
95. Principle 3
Secure Your Services
“security” by Dave Bleasdale. No alterations other than cropping.
https://www.flickr.com/photos/sidelong/3878741556/
Image used with permissions under Creative Commons license 2.0,
Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
96. Principle 3: Secure Your Services
• Defense-in-depth
• Network level (e.g. VPC, Security Groups, TLS)
• Server/container-level
• App-level
• IAM policies
• Gateway (“Front door”)
• API Throttling
• Authentication & Authorization
• Client-to-service, as well as service-to-service
• API Gateway: custom Lambda authorizers
• IAM-based Authentication
• Token-based auth (JWT tokens, OAuth 2.0)
• Secrets management
• S3 bucket policies + KMS + IAM
• Open-source tools (e.g. Vault, Keywhiz)
API Gateway
97. Principle 4
Be a good citizen
within the ecosystem
“Lamington National Park, rainforest” by Jussarian. No alterations other than cropping.
https://www.flickr.com/photos/kerr_at_large/87771074/
Image used with permissions under Creative Commons license 2.0,
Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
98. Hey Sally, we need to
call your micro-
service to fetch
restaurants details.
Sure Paul. Which APIs you
need to call? Once I know
better your use cases I’ll give
you permission to register
your service as a client on
our service’s directory entry.
Micro-service A Micro-service B
public API public API
Principle 4: Be a good citizen within the ecosystem
99. Principle 4: Be a good citizen within the ecosystem
(Have clear SLAs)
Restaurant
Micro-service
15 TPS100 TPS5 TPS20 TPS
Before we let you call
our micro-service we
need to understand
your use case, expected
load (TPS) and accepted
latency
100. …and many,
many
others!
Distributed monitoring and tracing
• “Is the service meeting its SLA?”
• “Which services were involved in a request?”
• “How did downstream dependencies perform?”
Shared metrics
• e.g. request time, time to first byte
Distributed tracing
• e.g. Zipkin, OpenTracing
User-experience metrics
Principle 4: Be a good citizen within the ecosystem
(Distributed monitoring, logging and tracing)
101. Principle 5
More than just
technology transformation
“rowing on the river in Bedford” by Matthew Hunt. No alterations other than cropping.
https://www.flickr.com/photos/mattphotos/19189529/
Image used with permissions under Creative Commons license 2.0,
Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
102. “Any organization that designs a system will
inevitably produce a design whose structure is
a copy of the organization’s
communication structure.”
Melvin E. Conway, 1967
Conway’s Law
103. Decentralize governance and data management
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
104. Decentralize governance and data management
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
105. Silo’d functional teams silo’d application architectures
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
106. Cross functional teams self-contained services
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
107. Cross functional teams self-contained services
Image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
108. Non-pizza image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
Cross functional teams self-contained services
(“Two-pizza teams” at Amazon)
109. Full ownership
Full accountability
Aligned incentives
“DevOps”
Non-pizza image from Martin Fowler’s article on microservices, at
http://martinfowler.com/articles/microservices.html
No alterations other than cropping.
Permission to reproduce: http://martinfowler.com/faq.html
Cross functional teams self-contained services
(“Two-pizza teams” at Amazon)
110. Principle 6
Automate Everything
“Robot” by Robin Zebrowski. No alterations other than cropping.
https://www.flickr.com/photos/firepile/438134733/
Image used with permissions under Creative Commons license 2.0,
Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
117. Principle 6: Automate everything
AWS
CodeCommit
AWS
CodePipeline
AWS
CodeDeploy
EC2 ELB
Auto
ScalingLambdaECS
DynamoDBRDS ElastiCache SQS SWF
SES SNS
API GatewayCloudWatch Cloud Trail
KinesisElastic
Beanstalk
118. It’s a journey…
Expect challenges along the way…
• Understanding of business domains
• Coordinating txns across multiple services
• Eventual Consistency
• Service discovery
• Lots of moving parts requires increased
coordination
• Complexity of testing / deploying /
operating a distributed system
• Cultural transformation
119. Principles of Microservices
1. Rely only on the public API
Hide your data
Document your APIs
Define a versioning strategy
2. Use the right tool for the job
Polygot persistence (data layer)
Polyglot frameworks (app layer)
3. Secure your services
Defense-in-depth
Authentication/authorization
6. Automate everything
Adopt DevOps
4. Be a good citizen within the ecosystem
Have SLAs
Distributed monitoring, logging, tracing
5. More than just technology transformation
Embrace organizational change
Favor small focused dev teams
122. Benefits of microservices
Rapid
Build/Test/Release
Cycles
Clear ownership and
accountability
Easier to scale
each
individual
micro-service
New releases
take minutes
Short time to add
new features
Easier to
maintain and
evolve system
Faster innovation
Delighted customers
Increased agility
123. Additional AWS resources:
• Zombie Microservices Workshop:
https://github.com/awslabs/aws-lambda-zombie-workshop
• Serverless Webapp - Reference Architecture:
https://github.com/awslabs/lambda-refarch-webapp
• Microservices with ECS:
https://aws.amazon.com/blogs/compute/using-amazon-
api-gateway-with-microservices-deployed-on-amazon-ecs/
• Serverless Service Discovery:
https://aws.amazon.com/blogs/developer/
serverless-service-discovery-part-1-get-started/
• ECS Service Discovery:
https://aws.amazon.com/blogs/compute/
service-discovery-an-amazon-ecs-reference-architecture/
• Microservices without the Servers
https://aws.amazon.com/blogs/compute/
microservices-without-the-servers
Popular open-source tools:
• Serverless – http://serverless.com
• Apex - http://apex.run/
https://aws.amazon.com/devops/
Additional resources
Remind audience that this is a 200-level session
Cover a lot of ground – we can fill a multi-day workshop
Ask “by show of hands”, how many are familiar with the idea of microservices.
How many have built out microservices?
And we continue to innovate on behalf of our customers. 90-95% of roadmap is based on what customers ask for.
And one of the reasons why customers choose the AWS platform is the speed of innovation, as we build more features that customers want.
But it wasn’t always this way.
But it wasn’t always this way. Amazon used to be built using a monolith architecture.
I don’t know about you, but around the year 2001, we found our own biggest bottleneck at Amazon.
At that time, it became increasingly difficult for our software developers to integrate new features into the Amazon.com page, understand the data that came in through our eCommerce operations and react quickly to customer feedback.
The reason was that the Amazon.com homepage had turned into this large, complex and difficult to maintain thing:
The Monolith.
Obidos, $3.2B in revenue, C++
Over time, the set of features on the Amazon website grew and the Obidos codebase began to sprawl. The binary was multiple gigabytes and took a very long time to compile. So, in the early-mid 2000s, the company began to switch over to Gurupa.Gurupa was a webserver that could only talk to databases and filesystems through BSF (Amazon in-house equivalent of Thrift), and then when these services gave the data to the server, it would assemble them into a webpage using Mason templates, which is basically Perl interspersed with HTML (feels similar to PHP).Over the period of about 2 1/2 years (I think) around 2004-2005, the company migrated from Obidos to Gurupa completely.
So at Amazon, we have this practice of doing the 5 Why’s…asking Why, to get to the root causes of the problem.
And we identified a few root causes.
And at Amazon, where it’s all about the customer, that just is not acceptable.
So at Amazon, one of our leadership principle is Dive Deep. practice of doing the 5 Why’s…asking Why, to get to the root causes of the problem.
And we identified a few root causes.
And what we started to understand as the root cause were two key ones:
- when you're working with a monolithic app, you have many developers all pushing changes through a shared release pipeline
- this causes frictions at many points of the lifecycle
- upfront during development, engineers need to coordinate their changes to make sure they're not making changes that will break someone else's code
- if you want to upgrade a shared library to take advantage of a new feature, you need to convince everyone else to upgrade at the same time – good luck with that
- and if you want to quickly push an important fix for your feature, you still need to merge it in with everyone else's in process changes
- this leads to "merge Fridays", or worse yet "merge weeks", where all the developers have to compile their changes and resolve any conflicts for the next release
- even after development, you also face overhead when you're pushing the changes through the delivery pipeline
- you need to re-build the entire app, run all of the test suites to make sure there are no regressions, and re-deploy the entire app
- to give you an idea of this overhead, Amazon had a central team whose sole job it was to deploy this monolithic app into production
- even if you're just making a one-line change in a tiny piece of code you own, you still need to go through this heavyweight process and wait to catch the next train leaving the station
- for a fast growth company trying to innovate and compete, this overhead and sluggishness was unacceptable
- the monolith became too big to scale efficiently so we made a couple of big changes
- one was architectural, and the other was organizational
Building complex applications is inherently difficult
Teams depend on each other’s libraries + other common libraries
“We’re blocked as we cannot build our software until you hand us the latest version of your library”
Teams depend on each other’s database schema
“We’re afraid the changes we’re making to our database schema will break your code”
Teams depend on each other’s libraries + other common libraries
“We’re blocked as we cannot build our software until you hand us the latest version of your library”
Teams depend on each other’s database schema
“We’re afraid the changes we’re making to our database schema will break your code”
Teams depend on each other’s libraries + other common libraries
“We’re blocked as we cannot build our software until you hand us the latest version of your library”
Teams depend on each other’s database schema
“We’re afraid the changes we’re making to our database schema will break your code”
We knew there had to be a better way.
So around this time, we implemented a company-wide mandate to decompose our monolith and EVOLVE towards microservices.
We knew there had to be a better way.
So around this time, we implemented a company-wide mandate to decompose our monolith and EVOLVE towards microservices.
So what defines a microservice?
You can certainly look it up on Wikipedia, but the succinct definition that I like the most, and that captures the essence of what a microservice is, is the definition by Adrian Cockcroft, one of the luminaries of cloud computing. The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans.
So what defines a microservice?
You can certainly look it up on Wikipedia, but the succinct definition that I like the most, and that captures the essence of what a microservice is, is the definition by Adrian Cockcroft, one of the luminaries of cloud computing. The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans.
So what defines a microservice?
You can certainly look it up on Wikipedia, but the concise definition that I like the most, and that captures the essence of what a microservice is, is the definition by Adrian Cockcroft, one of the luminaries of cloud computing. The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans.
So what defines a microservice?
You can certainly look it up on Wikipedia, but the concise definition that I like the most, and that captures the essence of what a microservice is, is the definition by Adrian Cockcroft, one of the luminaries of cloud computing. The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans.
So what defines a microservice?
You can certainly look it up on Wikipedia, but the concise definition that I like the most, and that captures the essence of what a microservice is, is the definition by Adrian Cockcroft, one of the luminaries of cloud computing. The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans.
So what defines a microservice?
You can certainly look it up on Wikipedia, but the concise definition that I like the most, and that captures the essence of what a microservice is, is the definition by Adrian Cockcroft, one of the luminaries of cloud computing. The concept of bounded contexts comes from the book Domain Driven Design by Eric Evans.
We knew there had to be a better way.
So around this time, we implemented a company-wide mandate to move towards microservices.
We knew there had to be a better way.
So around this time, we implemented a company-wide mandate to move towards microservices.
Anatomy of a microservice
TODO: Change to restaurantAPI
Anatomy of a microservice
TODO: Change to restaurantAPI
Anatomy of a microservice
TODO: Change to restaurantAPI
Anatomy of a microservice
TODO: Change to restaurantAPI
Allows you to avoid software coupling, because you know longer have shared libraries or shared datastores. Microservices just talk to one another via their public APIs.
Web of Microservices
2009
- what does success look like
- there are a lot of ways that you can measure the process, and no one way is perfect
- but here's one data point
- when you have thousands of independent teams
- producing highly-factored microservices
- that are deployed across multiple dev, test, and production environments
- in a continuous delivery process
- you get a lot of deployments
- at Amazon in 2014, we ran over 50M deployments
- that's an average of 1.5 deployments every second
TODO: Summarize the benefits that Nike was able to see
Or to put more simply….
Use the right tool for the job.
Or to put more simply….
Use the right tool for the job.
So with those two core principles as foundation, let’s build a microservice
Go Serverless
Go Serverless
Go Serverless
Go Serverless
Go Serverless
Go Serverless
Go Serverless
Go Serverless
Go Serverless
Go Serverless
Coursera
13 million users from 190 countries
1,000 courses from 119 institutions, everything from Programming in Python to Songwriting.
Coursera uses Amazon EC2 Container Service to manage a microservices -based architecture for its applications.
Now deploy software changes in minutes instead of hours in a resource-isolated environment.
Large monolithic application for processing batch jobs that was difficult to run, deploy, and scale.
A new thread was created whenever a new job needed to be completed, and each job took up different amounts of memory and CPU, continually creating inefficiencies.
A lack of resource isolation allowed memory-limit errors to bring down the entire application.
Each job is created as a container and Amazon ECS schedules the container across the cluster of EC2 instances. ECS handles all the cluster management and container orchestration, and containers provide the necessary resource isolation.
Prototype up and running in <2 months
Speed and agility: Software deployment time went from hours to minutes
Each team can now develop and update its respective applications independently
Operational efficiency: No extra infrastructure engineering time is spent installing software and maintaining a cluster—Amazon ECS handles everything from cluster management to container orchestration.
Go Serverless
Go Serverless
Go Serverless
Go Serverless
“Simplest way to build powerful, dynamic apps in the cloud”
“Simplest way to build powerful, dynamic apps in the cloud”
“Simplest way to build powerful, dynamic apps in the cloud”
“Simplest way to build powerful, dynamic apps in the cloud”
“Simplest way to build powerful, dynamic apps in the cloud”
“Simplest way to build powerful, dynamic apps in the cloud”
Abstracts the implementation so that you can switch from Lambda to EC2 or Combine multiple backends. Similarly you can use mapping templates to unify different versions of your APIs
Network protection is something we do very well and requires hyperscale, you won’t be able to auto-scale to meet an attack, let us do it
Centralize authorization decisions in a policy and remove the concern from the code in your backend, fewer bugs
Abstracts the implementation so that you can switch from Lambda to EC2 or Combine multiple backends. Similarly you can use mapping templates to unify different versions of your APIs
Network protection is something we do very well and requires hyperscale, you won’t be able to auto-scale to meet an attack, let us do it
Centralize authorization decisions in a policy and remove the concern from the code in your backend, fewer bugs
Abstracts the implementation so that you can switch from Lambda to EC2 or Combine multiple backends. Similarly you can use mapping templates to unify different versions of your APIs
Network protection is something we do very well and requires hyperscale, you won’t be able to auto-scale to meet an attack, let us do it
Centralize authorization decisions in a policy and remove the concern from the code in your backend, fewer bugs
Abstracts the implementation so that you can switch from Lambda to EC2 or Combine multiple backends. Similarly you can use mapping templates to unify different versions of your APIs
Network protection is something we do very well and requires hyperscale, you won’t be able to auto-scale to meet an attack, let us do it
Centralize authorization decisions in a policy and remove the concern from the code in your backend, fewer bugs
Demo: Build a microservice using Lambda and API gateway
Emphasize the versioning aspect of microservices
Test the service using Postman
Export out the Swagger definition
Use Swagger tool to generate documentation
Show that you can generate client libraries
Go Serverless
Go Serverless
Go Serverless
Go Serverless
Go Serverless
Demo: Build a microservice using Lambda and API gateway
Emphasize the versioning aspect of microservices
Test the service using Postman
Export out the Swagger definition
Use Swagger tool to generate documentation
Show that you can generate client libraries
Go Serverless
All this promotes agile experimentation
Web of Microservices
Or to put more simply….
Use the right tool for the job.
Or to put more simply….
Use the right tool for the job.
This goes both ways:
Service registry
Service owners have a responsibility – publish your health, monitorClients have a responsibility to do exponential backoff – in case there are errors
This goes both ways:
Service owners have a responsibility – publish your health, monitorClients have a responsibility to do exponential backoff – in case there are errors
If it moves, it should be tracked and logged
Spend more time working on code that analyses the meaning of metrics than code that collects, moves, stores and displays metrics
Reduce key business metric latency to less than the human attention span (~10s)
Validate your measurement system has enough accuracy and precision. Collect histograms of response time
Monitoring systems need to be more available and scalable than the systems (and services) being monitored
Optimise for monitoring distributed, ephemeral, 'cloud-native', containerised microservices
Fit metrics to models in order to understand relationships (this is a new rule)
Or to put more simply….
Use the right tool for the job.
It’s about communication between teams.
So, it’s not only about changing
the software architecture,
but also changing the way
software teams are organized.
- in conjunction with breaking apart the architecture, we also broke apart the organization
- we split up the hierarchical org into small teams
- we called them 2-pizza teams, because if they got larger than you could feed with 2 pizzas, we'd break them up
- in reality, the target number is about 8 people per team, so I personally think the 2 pizza goal is maybe a little too frugal
- another important change that went along with this is cultural
- when we split up the org, we gave the teams full autonomy
- they became small startups that owned every aspect of their service
- they worked directly with their customers (internal or external), set their roadmap, designed their features, wrote the code, ran the tests, deployed to production, and operated it
- if there was pain anywhere in the process they felt it
- operational issue in the middle of the night, the team was paged
- lack of tests breaking customers, the team got a bunch of support tickets
- that motivation ensured the team focused on all aspects of the software lifecycle, broke down any barriers between the phases, and made the process flow as efficiently as possible
- we didn't have this term at the time, but this was the start of our "DevOps" culture
- in conjunction with breaking apart the architecture, we also broke apart the organization
- we split up the hierarchical org into small teams
- we called them 2-pizza teams, because if they got larger than you could feed with 2 pizzas, we'd break them up
- in reality, the target number is about 8 people per team, so I personally think the 2 pizza goal is maybe a little too frugal
- another important change that went along with this is cultural
- when we split up the org, we gave the teams full autonomy
- they became small startups that owned every aspect of their service
- they worked directly with their customers (internal or external), set their roadmap, designed their features, wrote the code, ran the tests, deployed to production, and operated it
- if there was pain anywhere in the process they felt it
- operational issue in the middle of the night, the team was paged
- lack of tests breaking customers, the team got a bunch of support tickets
- that motivation ensured the team focused on all aspects of the software lifecycle, broke down any barriers between the phases, and made the process flow as efficiently as possible
- we didn't have this term at the time, but this was the start of our "DevOps" culture
Or to put more simply….
Use the right tool for the job.
- with these new tools, we completed the puzzle
- the teams were decoupled and they had the tools necessary to efficiently release on their own
- with these new tools, we completed the puzzle
- the teams were decoupled and they had the tools necessary to efficiently release on their own
- with these new tools, we completed the puzzle
- the teams were decoupled and they had the tools necessary to efficiently release on their own
- with these new tools, we completed the puzzle
- the teams were decoupled and they had the tools necessary to efficiently release on their own
- with these new tools, we completed the puzzle
- the teams were decoupled and they had the tools necessary to efficiently release on their own
- with these new tools, we completed the puzzle
- the teams were decoupled and they had the tools necessary to efficiently release on their own
But more important than the technologies are the principles we talked about.
Put this perspective
- Operating a monolith may be easier
- When you can’t innovate quickly
- Understand your domain
So at Amazon, we have this practice of doing the 5 Why’s…asking Why, to get to the root causes of the problem.
And we identified a few root causes.
So at Amazon, we have this practice of doing the 5 Why’s…asking Why, to get to the root causes of the problem.
And we identified a few root causes.
So at Amazon, we have this practice of doing the 5 Why’s…asking Why, to get to the root causes of the problem.
And we identified a few root causes.
There’s no shortage of resources
So at Amazon, we have this practice of doing the 5 Why’s…asking Why, to get to the root causes of the problem.
And we identified a few root causes.