location_on United States
Member since 1 year
Nikhil Barthwal is passionate about building distributed systems. He has several years of work experience in both big companies & smaller startups and also acts as a mentor to several startups. Currently, He is Product Manager in Google Cloud Platform working on Google Cloud's Serverless products. Outside of work, he speaks at local meetups as well as international conferences on several topics related to Distributed systems & Programming Languages.
Managing Modern Serverless Workloads Using Knative & Cloud RunNikhil BarthwalProduct Manager
schedule 3 months agoSold Out!
This introduces Knative & Cloud Run and shows how they can be used to run modern serverless workloads. Knative is a reference API &
implementation and Cloud Run is a product built on the Knative specification.
Knative is a Kubernetes-based platform to build, deploy, and manage modern serverless workloads. It provides a set of middleware
components that are essential to build modern, source-centric, and container-based applications. Knative components are built on
Kubernetes and codify the best practices shared by successful real-world Kubernetes-based frameworks.
Cloud Run is a managed compute platform that is built upon Knative that automatically scales your stateless containers. Cloud Run
is serverless: it abstracts away all infrastructure management. It is compatible with Knative, letting you choose to easily run
your containers either fully managed with Cloud Run, or in your Google Kubernetes Engine cluster with Cloud Run on GKE.
Implementing Event-Driven Microservices architecture in Functional language
Web services are typically stateless entities, that need to operate at scale at large. Functional paradigm can be used to model these web services work and offer several benefits like scalability, productivity, and correctness.
This talk describes how to implement Event-Driven Microservices with examples in F#. It starts with introducing Domain Driven Design to create Microservices boundaries. Using Discriminated Unions (F#'s Algebraic Data Types), the domain model can be captured as code eliminating the need for separate documentation. Moreover, using Computation expressions (F#'s Monads), one can model custom workflows easily.
It then introduces event-driven architecture, where every external action generates an event that the system responds to. Events act as the notification messages for any significant change in state and may generate other event(s) as services invoke each other. They are immutable by nature.
An explanation on why 2-phase commits cannot be used in Microservices having their own databases. Further the talk explains, how Event Driven Architecture solves this problem in an eventually consistent manner without sacrificing availability or partition tolerance. Distributed Sagas as a protocol for coordinating Microservices is introduced and its implementation in F# is also provided.
Event Sourcing can be used to model the system state. Event sourcing models the state of entity as a sequence of state-changing events. Whenever the state of a business entity changes, a new event is appended. List fold operation is ideal for implementing Event sourcing where the application reconstructs an entity's current state by replaying the events. An example with F#'s List.fold is provided.
Some aspects of evolutionary architecture are also discussed, particularly on how to evolve Microservices interface. F#'s Type providers can be used for the same though there are alternate approaches using Apache Thrift/Google Protobuf (They don't have support for F# but they do have support for C#, which F# code can leverage).
Events and their responses can be very easily modeled with Discriminated Unions. Data immutability captures the behavior of these events, since events are immutable by nature. A service can be thought of as a function that accepts an event (input) and gives back a response (output). A service may call other services, which is equivalent to a function calling other functions or even Higher-Order functions.
Immutability allows infinite scalability as it eliminated the need to worry about a mutex, a lock, or a race. As functional code is much more terse compares to object-oriented code, it provides productivity benefits. Its strict typing makes writing correct code easy as mismatch of types are caught at compile time.
Most of the services are implemented as set of pure functions. These functions which have no internal state, where outputs depend only on inputs and constants and it is very easy to test such functions. The absence of internal state means that there are no state transitions to test. The only testing left is to collect a bunch of inputs that tests for all the boundary conditions, pass each through the function under test and validate the output.
The objective of the talk is to show how to create a scalable & highly distributed web service in F#, and demonstrate how various characteristics of functional paradigm captures the behavior of such services architecture very naturally.
Embracing Functional Paradigm in F# for Enhanced Productivity
F# is a relatively new primarily Functional programming language for the .NET platform. It is a statically typed managed functional language that is fully inter-operable with other .NET languages like C#, Visual Basic.NET etc. It builds on the power of Functional Paradigm and combines it with .NET Object-Oriented model enabling the developer to use the best approach for a given problem.
This workshop introduces Functional Programming in F# from ground up. No prior experience in Functional Programming or .NET is needed, familiarity with a mainstream programming language like C++/Java/C# should be enough.
Functional programming (FP) offers several benefits. The code tends to be terse which leads to enhanced developer productivity. FP encourages pure functions which are much easier to reason about and debug, as well as eliminates large class of bugs due to side effect free programming. Moreover, immutability leads to easy parallelization of the code. Algebraic Data Types can be used to express domain object conveniently and control state space explosion.
F# is great practical choice for developing reliable and highly scalable real-world system that are quick and easy to develop due to the design of the language itself combined with the ability of the language to use a large no. of 3rd party libraries designed for the .NET platform.
Unfortunately, support for multiple paradigms often leads to confusion. Newcomers tend to find the transition from object-oriented world to functional world difficult. Moreover, it often leads to abuse where developer tries to use the same old imperative style of coding in a functional language and is unable to take advantage of the features, the language has to offer.
Serverless Application Development using Azure Functions
Serverless computing is a cloud computing execution model in which the cloud provider dynamically manages the allocation of machine resources. Typically, applications consist of stateless custom code that's run in ephemeral containers (Function as a Service or "FaaS"), which be spun up on demand. As a result of it, serverless applications tend to be highly scalable.
The objective of the talk is to show how to build and deploy elastic-scale applications serverless applications. The code examples for the talk are in C# and using Azure Functions.
Azure Functions is Serverless offering by Microsoft and is an event driven, compute-on-demand experience that extends the existing Azure application platform with capabilities to implement code triggered by events occurring in Azure or third-party service as well as on-premises systems.
Chaos Engineering: Building Immunity in Production systems
Modern software-based services are implemented as large scale, highly distributed systems running in cloud or data centers. Disruptive real-world events like hardware failures or software bugs can create turbulent conditions in the environments where these systems and can lead to unpredictable outcomes. Chaos Engineering is a study of system’s ability to withstand such disruptive turbulent conditions. It works by purposefully injecting failure into the production environment that mirrors the actual failure modes and monitors the recovery.
Chaos engineering uses experimentation to study effects of such disruptions. These experiments typically start by defining “steady state” of the system and come up with metrics that can be used to measure this steady state. Then various events that mirror the failure modes (aka “Chaos”) that are possible in our production environment (e.g. server crash), are injected systematically in the system in controlled environment.
Effect of the injected “Chaos” is observed by collecting and analyzing the metrics identified above. If the system is able to recover successfully, this builds confidence in system’s ability to handle an actual unplanned outage.
If a failure to recover is observed, then it becomes a target for improvement before that behavior manifests in the system at large. By continuing to run these simulations, it is possible to identify several such vulnerabilities. Fixing these vulnerabilities strengthens the system over a period of time. Extensive monitoring and logging is essential for the success of Chaos Engineering in its goal to improve the resiliency of the system.
Unikernels: The Next Evolution in Cloud Infrastructure
Unikernels are specialized, single address space machine image constructed by using library operating systems and are gaining a lot of attention in the industry. Due to less amount of code deployed, they have smaller attack surface and hence improved security.
This talk describes what Unikernels are, what are their advantages & disadvantages and how are they different from containers & microkernels. It uses MirageOS as an example to show how the developer selects the minimal set of libraries which correspond to the OS constructs required for their application to run and these libraries are then compiled with the application to build sealed, fixed-purpose images which run directly on a hypervisor or hardware without an intervening OS.
No more submissions exist.
No more submissions exist.