Mete Atamel
Software Engineer and Developer Advocate at Google
London, United Kingdom
I’m a Software Engineer and a Developer Advocate at Google in London. I build tools, demos, tutorials, and give talks to educate and help developers to be successful on Google Cloud.
Awards
Area of Expertise
Topics
Open standards for building event-driven applications in the cloud
AsyncAPI is an open-source specification for describing and documenting asynchronous APIs, similar to OpenAPI specification for documenting RESTful APIs. CloudEvents is a specification for event data in the cloud. Together, they enable developers to design, document, and test event-driven APIs and to easily share and consume event data across different cloud platforms and ecosystems.
In this session, we will explore the benefits of using AsyncAPI and CloudEvents in your tech stack, and how they can help you build asynchronous, event-driven applications that are
well-documented and easy to maintain.
A comparison and best practices for service communication
When you have a fleet of services, you need to decide how they should communicate with each other. There are several options to consider: direct calls, indirect events, a central orchestrator, or a combination. We will explore the pros and cons of each style and provide guidance on how to choose the best one for your needs.
If you decide to use a central orchestrator, there are several best practices you can follow to ensure that your system is reliable and easy to maintain. We will dive into these best practices, including handling service failures, implementing retries, using the saga pattern, and incorporating GitOps practices into your workflow.
Serverless landscape beyond functions
Serverless is much more than simple HTTP triggered functions. You can run containers and whole apps serverlessly, group functions behind an API gateway, coordinate services with a central orchestrator or let them communicate indirectly via events. You can schedule services or make them more resilient with task queues. You can even combine serverless orchestration with serverful services. In this talk, we’ll look at the serverless landscape beyond simple functions and explore some patterns that help with serverless applications.
Pic-a-daily Serverless Workshop
In this workshop, attendees discover the various serverless options offered by Google Cloud Platform, such as Cloud Functions (functions as a service), App Engine (application as a service), and Cloud Run (container as a service). Attendees create an application that lets users upload, analyse, and share pictures. Data will be stored in Cloud Storage (images), Cloud Firestore (structured data). Along the way, additional services will be used such as Vision API (to analyze pictures), Cloud Logging (to track interesting events), Cloud Scheduler (to invoke workloads on a schedule), Cloud Pub/Sub, Eventarc (to receive events) and Workflows (to orchestrate services).
Service orchestration patterns
Once you have a fleet of services, you need to decide how to organize and get them to cooperate for a common goal. Should they communicate with direct calls? Or should they communicate indirectly in a loosely coupled way via events? Maybe a central orchestrator should direct the communication? What do you do when a service fails? When to use a simple retry or a more sophisticated Saga pattern? In this talk, we?ll look at some orchestration patterns and techniques and to get your services to cooperate in a resilient way.
Serverless with Knative
When you build a serverless app, you either tie yourself to a cloud provider, or you end up building your own serverless stack. Knative provides a better choice. Knative extends Kubernetes to provide a set of middleware components for modern, source-centric, and container-based apps that can run anywhere. In this talk, we’ll see how we can use Knative primitives and its managed cousin Cloud Run.
Choreography vs Orchestration in serverless microservices
We went from a single monolith to a set of microservices that are small, lightweight, and easy to implement. Microservices enable reusability, make it easier to change and scale apps on demand but they also introduce new problems. How do microservices interact with each other toward a common goal? How do you figure out what went wrong when a business process composed of several microservices fails? Should there be a central orchestrator controlling all interactions between services or should each service work independently, in a loosely coupled way, and only interact through shared events? In this talk, we’ll explore the Choreography vs Orchestration question and see demos of some of the tools that can help.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top