About this talk
In this talk, the speaker discusses the development of cloud applications using the Service Weaver framework, particularly focusing on its use with Go programming. The speaker, a developer advocate, explains the challenges developers face when working with microservices, such as defining service boundaries and architecture choices. He introduces the concept of modular binaries that allow developers to build applications without committing to a specific architecture upfront, thereby delaying the decision between microservices and monoliths. The talk includes a demonstration of how Service Weaver simplifies code organization, deployment, and management, as well as how it provides essential features like service discovery and built-in telemetry.
Full transcript
hello everyone uh we are here with our next talk and uh I would like you to welcome Abel a good friend uh that we I now know for quite some time uh he is also the co-host of the Cates podcast by Google and he will talk about modern development of cloud applications with service Weaver enjoy and have fun thanks for being here thank you I'll try thank
you everyone um can I get my yeah thank you all right cool cool um before I get started how many people here are go developers or write coding go oh fful okay cool that's pretty cool okay so hopefully you enjoy this um that's because service Weaver is a go framework right so um um if you've never really even if you're not a go developer and you don't
write coding go um if you're familiar with there is a framework that Microsoft released few years ago called Dapper d a r I think you some of you heard of it maybe one of person okay um it's kind of the same concept anyway so my name is abdell I'm a developer Advocate uh based in Stockholm Sweden um I basically work mostly on um containers and kubernetes stuff
that's why I host the kubernetes podcast and um I also do go right um I an old school developer I came from the Java and Bash World um arguably one of the best programming languages in the world bash and then I kind kind of like graduated toward go and um I'm in the process of learning rest and I got interested in this project when we open source
it last year or two years ago um because it's actually pretty cool so I'll show you something so okay micros services are popular you know there's a lot of things um that that people use for doing microservices I'm not going to bore you with this details the the main problem that are that that that are associated to microservices is that there is no no one knows how
to do them right like no one really have like there is no such a thing as a guide for the perfect way of doing microservices um it's actually so bad that the the community or us the tech people invented a new word which I just discovered this week and I'm going to share it with you I don't know if you know it's macro Services have anybody heard
of macros Services no okay so apparently there is monolith right and there are microservices and then somebody some I don't know who this person is invented a word called microservices and microservices are essentially it's supposed to be the best of both walls it's the services that are the right size whatever the right size is right because that's the one of the biggest problem micros services like what's
the right size of a microservice is it supposed to be big or small or XL or dou XL or M or whatever um most people think that microservices are like the way to go like the the so these are all comments by the way we collected um from the Y combinator um uh um uh um Reddit kind of thing um um a lot of people think that
that they're doing Microsoft is the wrong way in the sense that they don't know how to draw the boundaries like exact where exactly does one service stops and another service starts right um um most essentially just anti monolit right that's kind of seems to be the case um and most people think that micros services are okay but the problem is people the problem is that the people
that Implement micr don't know what they're doing and they are the one that cause all the problems right um um and then seems like a lot of people actually don't know what if they're doing microservices or mon applications or combination of both right and these are just comments we collected so the the one of the big one the BG the biggest problems with that the there is
this like I call this the Fang effect Fang starts for like Facebook Apple Google like all the big companies right and the Fang effect essentially is when any of these big companies publish an article where they say we went from this architecture to this architecture and it helped us solve solve 99% of our problems the entire tech industry just follows them right because everybody thinks that they
are Google everybody thinks that they are writing a service that is used by one billion users and everybody thinks that whatever Google publishes is the right way to go um and that's actually the wrong that's actually really bad that's like the wrong type of influence we don't want people to be doing that we want people to be to be able to do thing that Mak sense for
their application and uh just to illustrate my points um H have anybody seen this article um few years few weeks ago few months ago um from AWS uh the AWS Prime the video streaming service one person one okay two people okay so let me give you the tldr so um inside AWS Prime which is the video streaming service right uh some team does um uh they are
responsible for video quality right so what they're what what they're supposed to do is that they're supposed to catch the stream of the videos and analyze them to verify if they are streaming good sorry good quality videos right and so they obviously use AWS right so what they did is they rot a service that um uh that that does um you know like quality analysis on the
videos and the way they wrote it is that they used AWS Lambda and uh so they wrote One function that CT that that captures the stream and then split it into individual frames right so if they are framing or if they're streaming a 4K video at 30 frames per second so that's one frame per second so 30 pictures per second of video right so again let's let's
reiterate you know how AWS Lambda works right it's a function and then each time you trigger a function you pay for it so for every single video they were triggering the function 30 times per second for every video right so they wrote two functions like one function that basically captures the the the the videos uh splits it into the individual frames and another function that does the
actual quality analysis right and so they they wrote this application this way and then they realized well it doesn't scale it cost too much all that stuff so they just fall back into using ECS uh elastic container services the container tool from ews right um which essentially is a mon application so they they took these two functions they just smooch them together wrote one single application that
does both the frame splitting and the analysis and then they wrote this article which says by moving from microservices to monori we save 90% of the cost and a lot of people were like yes of course what the you know like of course from moving from individually triggered f to a single application with a single process you're going to save cost right so this is just to
illustrate the point of why microservices are very hard because when you start doing things especially if you're writing a new application um if you really don't know what you're are doing you might do what ews did right or what these people at ews did you might go with one architecture and then you realize later it doesn't work and then you switch back to monoliths and then you
save on cost and you're like oh mon is better than so the is the reason the reason why this is a problem is because there is basically no official guidance for how to do microservices like there is nothing there's like no such a thing like there articles and um I hate to break this to you um like 99% of tech Publications are opinions like people just publish
their opinions that like no one no one knows what the they're doing like people publish the stuff that they think are the right way to do things and um actually it's even worse than that because um um um I started blogging few years ago and I was using medium and I realized that like on medium there are actually people that publishes articles that are um how does
Uber uh you know connect drivers to users and these people don't work for Uber they just like speculate how Uber works and it's just like it's so bad it's really bad so there is no official guideline that's the problem microservices are not neither good neither bad it's about a trade-off right do you what do you want to trade off do you trade trade off the ease of
deployment versus the ease of Maintenance do you trade off the ease of scaling versus the ease of not scaling does your application actually need scaling if your application is used by two users who probably don't care and the the the on top of all of this the fact that we are in the cloud environment or in the cloud first world if essentially it makes things even worse
because you know things are complicated cloud is complicated people have to learn a lot of things um um is anybody here a full stock developer all I hey hate to break it to you you are not and there is not such thing as full stock developers people like you either know front end you know back end or you know databases you cannot know all of them right
just just let's just make it this way that that that's that's I'm I'm just I'm not I'm not on you the point I'm trying to make here is that like you cannot be good at everything you have to be good at one thing and you have to be okay at other stuff right um or you can just be like me and usually what I tell my manager
is that I am mediocre at everything um so I try to be okay at some stuff so what we did is we we came we we basically looked at all these problems and we came up with an idea of how can we make micros Services developer development easy for people and so the way we could do it or one way we could do it is if we
could write a modular binary a modular binary essentially it's a single binary but in it we can split code in a logical way into modules and then those modules can be together as a as a month application or they can be split into microservices later the idea of service Weaver is to delay this this decision of doing microservices and Mones as far as possible if you are
starting to write your code today you don't have to worry too much today about whether you want to do microservices or mons you can delay that decision later um so how does it work so service Weaver basically works on four different fronts deel developments so how do you organize your code how do you connect the modules together how do you deploy the application itself you can deploy
it as single binary you can deploy it as multiple binaries or you can deploy it as containers into communities um performance I'm going to show you a little bit some some benchmarks later and then we built into it metrics login tracing etc etc so for development we basically use uh um the in in in in a in um in a um um sorry in a in a
go we use the concept of interfaces so each interface this is component and each component is basically implemented um as an interface right so here this is an example where I have three components rock paper scissor and then I can either run them locally as together as one process or I can just decide to run them as multiple processes I'm going to show you an example later
so how do we Define a component a component is just an interface um so we Define a type interface inside that interface we have a function which is the actual function of the of the interface itself then to implement the interface or to implement the component we use this function called weaver. implements um and then we call the function and then if we want to instantiate or
use the the interface somewhere else we just need to use the weaver. ref so weaver. ref is the instantiation and then weav implements is the actual implementation when we pass an interface to Weaver through the implements function that basically tells the service Weaver that you should webify we call it webify essentially means this component is now part of service Weaver framework so the framework is aware of
it so that later on if we need to split this up to give you a very concrete example if we want to take this cache component and run it as its own individual um microservice then Weaver will implement the underlying grpc code for it so it will generate all the grpc all the protos all that stuff so you don't have to worry too much about it so
and then yeah then then you basically um um call the Weaver um so in in where you need to use the the the the the application you just need to call the weaver. Run um uh function to be able to call the the the object or the interface so let me show you an example a very very stupid example uh uh let's see I have it here
uh I think I have uh yes hello world CD examples um and then I think I have an example inside the H hello world give me one yeah or maybe let's let's try this one um so okay so inside this um uh uh component called hello world I have an interface here um it's called reverser it's implemented as an interface it has a function called reverse and
then um to implement it I just use the weaver. implements and then if I want to call it I literally have to just uh I need to be a to call the we call the interface through the ref uh command so through the ref I can I can instantiate or import if you want and then um where is basically what I have to do is I just
call the app. reverser doget and doget will call the function for me reverse that's the actual function inside the interface sorry app. reverser doget will get the interface and then reverse is the actual function if I go back here um inside the reverser function I have an uh inside the reversal interface I have a function called reverse and this is how I call it so um uh
reference it and then um call it this way so let's go here do this uh so basically I just need to do um a Go slash run and I think uh hold on a second I haven't tried this for a while let's see yeah that should be and then I should be able to just Cur do a curl on this here what uh okay that doesn't work
why ah okay ah uh different port 41 399 uh 93 what okay didn't work for some reason okay I don't know why um maybe I can call it this way let's see uh no uh slash ah come on slash hello yeah okay so um yeah you can probably see it here it's very small sorry about that um yeah so the the function has an endpoint called hello
and um um because in the application itself uh what I did is I I I I try to I try to get whatever message is passed and if it's not passed I just default to hello to W and just reverse w for me right so to recap reverser is a component it's an interface main is the actual main application through main I call the Weaver through the
reference um function and then I do the the app. revers do get to get the fun the the the interface and then do reverse is what gets me the actual function that I need right so uh pretty straightforward right um can I show you another example actually give me a second uh let's see close all of this and let's see I haven't think I think I have
um a thing here examples chat let's see if chat works I think chat should work uh or no is it chat that I want to show or hello world let's see yeah okay um I'm gonna okay so if you want to so if without doing anything like without you don't have to have this weaver. TL file this is just a configuration file that allows you to configure
extra parameters of Weaver itself um the the most basic example is this one that I showed earlier where I just have okay I have a service Weaver and basically I say I have single binary and the binary is just called hello world this is like the most basic example um I'll show what that what that tomal tml file means so releasing I can release my function as
a single binary um this is essenti was I just showed um single application single binary um or I can deploy it into um uh multiple binaries or multiple components or multiple applications um so in order to do the multiple deployments I need the TL file and in the TL file I can specify if I want to deploy locally if I want to do a deployment to multiple
machines you can actually put your public sh Keys into the file and then decide if you want to deploy the the the application or the components to multiple virtual machines or physical servers or I can deploy to kubernetes right and it will generate all the kubernetes code for me um so this is an example um the first example is a single binary the second example is SSH
and the third example is uh using kubernetes this is a particular example which uses gke which is our version of kubernetes Google kubernetes engine but it it just works with like regular kubernetes and then to deploy it's essentially as simple as um Weaver multi- deploy um so go/ run will run a single process uh Weaver multi- deploy will run a multiprocess SSH or gke or kubernetes and
so that's the example I wanted to show next um so I showed the hello world example so I'm going to show this one EXA actually um which is the one inside the hello example yes so this is an example where if I just do a go SL run like I did earlier it will just um release a single binary called hello but you you one one problem
here you might notice is that it it defaults to like random ports if you don't want to do that you can single uh deploy and then I need a config file uh how do I specify the config file uh yeah uh weaver. TL so if I run weaver. single deploy uh and then I specify the file then it will read from from the file and in this
case it will start on 1 2 3 4 5 right um so if I go back here uh to this end point somewhere um uh 1 2 3 4 five uh yeah then it just works right uh very simple um now this is not as impressive as an example but let let's see um actually one thing I didn't I didn't I didn't show I forgot to show
is that Weaver itself the command line has a built-in status so if you're debugging your application you can do uh Weaver status and it will tell me okay I have one deployment I have one application the application has two components there is the Weaver components uh the reversal component and then the Weaver main component and then um um then it's listening on one port one 2 3
4 5 that's because service Weaver actually was designed for backend applications and so for backend applications you need a port um I can also do something so if I stop this and I just uh replace this single multi uh what it will do essentially is um you remember in my in my example here I have two components I have the main component and the reversal components um
it will basically take that those two components and run them as two separate processes uh it should ah no okay so of course then I have to do multi um status and then okay so now I have two different processes and you can see that each process has its own P ID so now I have my main function and my uh reversal function running as two different
processes um on my laptop and they're like talking to each other through grpc um again I don't I don't need to show the example I don't need to show it's working but you get the point um and then if I want to deploy to kubernetes then I need to just do the same thing with the Weaver function and do kubernetes for example uh and I'm quite sure
that this will not work uh because Cube sorry uh deploy Weaver do. TL okay this is not going to work for this example I do have another example here which has the cube uh deployment I think hopefully somewhere let's see uh not the chat function which one oh damn um not the hello world not the reverse the reversal one let's see revers one has the cube one
oh it doesn't Okay um doesn't um B basically the point I'm trying to make is you we have a sub function called Cube and you can just run the cube command with the Weaver command line and it will either deploy or generate just the kubernetes files for you so if you don't want to worry too much about shaml and writing kubernetes files it will generate those so
that's for deployment again tldr you create an interface you implement the interface through the the the the Implement command you reference it through the ref command and then you call it through the get command as simple as that right um deployment you can do deploy as a single you can deploy as multiple you can deploy as a kubernetes um or to GK directly um if you are
deploying to kues you can actually specify directly some very specific KU stuff so um if you are familiar with the concept of kubernetes for requests and limits when you're deploying application to kubernetes you can decide how much requests you want how much resources you want to assign to your application in terms of CPU and and memory so then you can specify that directly into the the the
the cube. file so new file uh and then you deploy you specify how you want your application to be deployed um if there is anything that kubernetes requires you can specify directly inside the the cube file and then it comes with built in Telemetry so it's has built in promethus buil built in yagger and um through promethus you can just plug in grafana get Telemetry out of
the box um and then it also has like uh builtin um um uh support for like cic systems like Argo and Jenkin and all this stuff uh so we talked about the deployment how do you run the yeah so under the hood what wer really do does is it implements its own libraries and these libraries will Implement all the communication between the process you need so if
you need to do multi process or multi applications um again AKA microservices then Android Hood Weaver will generate all the grpc stabs all the files for you and then um um and then it will also do um all the uh service Discovery so that that's the parts I wanted to show and you will have to bear with me because I don't remember where the example is that
I want to show so give me a second I'm going to have to figure it out uh Weaver h that's not what I want uh this is blah blah multi uh do I have the cube one here do yes I think I do in this example the problem is I don't remember where is the itself but let's see uh how to run kubernetes blah blah shell Cube
CTL my SQL good uh blah blah blah and then update repo field in uh ah yeah here here I have it here sorry sorry about that yeah yeah okay okay so this is this is an example of of how do do we do with kubernetes right um so if I go inside this folder okay so let's uh let me show you what this example does so I'm
going to open the here which is I think the server. go yes so I have um my main function inside the server. goo file so basically this is implementing the main function and then inside of it I have four different components I have a component called store scaler cache and chat and each of those are its own um file right so each of them is a interface
uh which is implemented through the interface type in a in a in a in a in a in go and then um inside of it I have um so this is the interface itself called SQL store and then you have the functions whatever that interface needs to do and then the server. go is the file that just you know group all these things together so I just
call the SQL store the image scaler and the local cache through the ref command I implement the main function through the weaver. implements command and then I have my weaver. TL here which specify if I want to run it as a single binary it will compile all of this is single binary called chat but if I want to run it as multiple binaries it will listen on
Port 9,000 it doesn't matter but what's important here is this file here called Cube deploy so in the cube deploy file I specify um the Weaver file I need I specify the repository so that's essentially where do you want to push the images because it will also build the images for you by the way um thank you uh and then it specify uh what is the actual
listener so um which component of all these components is going to be the public one so if I I go here and I do Weaver uh Cube Weaver deploy uh Weaver uh. TL uh or cube deploy do ah okay here we go so um what it will do essentially is that it will look at the configuration file and then read the code and then it will build
an image for every single component so because I have four different components the server is one of them and then I have three more components each of them will result into building an image and uh this is going to fail I think because I need to authenticate but it doesn't matter but essentially what it will do is that it will build a component or a container for
every single uh component and then push those to my container registry and generate all the uh yaml files for my kubernetes deployment I think I will want to show it anyway because uh um gcloud out login um sorry should have done this before uh uh just pretend you're not looking at what I'm doing right now um because I'm not supposed to show you this well I mean
it's okay I'm not going to show you my password but there will be one piece of code you're not supposed to look at uh which uh I think it's going to be fine if I still show it uh where is my code here there we go uh all right my password is there I go there I put my password without showing it good we're still good authenticate
with my second Factor authentication next this is the part you're not supposed to see come on do something yeah okay cool continue allow this is the part you're not supposed to see okay uh let's pretend you didn't see it okay good good so um I'll do this again and meanwhile I'll just go here and I'll just refresh my uh uh go Cloud console and I'll show you
uh artifact registry uh switch the projects one second boom and then that should basically drop me into our so this is just our Google uh Cloud built in artifact registry um you can use whatever artifact registry you want uh I think in my case I push them into Europe nor one so they should be there so if we go into containers I should be able to see
that I have uh my chat application um uh which is a single container but I can also build it as multiple containers right so if I delete this one more time and just do that uh then it should just build the container and then push it into my container registry I don't need to show you more details I think it's I think the IDE is pretty clear
right like just generate uh yam files generate the components and then if I look into this file here this is the most important one um this is essentially my yl file so it generated also the yl file for me for the kuy deployment right um again I didn't write any Docker files right I didn't write any yamama files I didn't do all of that BS I just
wrot code run Weaver generated all the images for me and that did all the magic behind the scene for me so I don't have to worry too much about it so um yeah that's it that's basically the tldr of what service Weaver do um uh let me go back to my slides I just still want to finish few things and I will leave some time for for
questions at the end um yes so we did we did some bsh marking what we did actually is we took this application called online boutique it's an app that we we people in my team rot and uh it's a microsof say app that we initially wrot to demonstrate ISO service match uh but then we we basically um use it for all sorts of things it's written in
multiple uh programming languages um uh some of them are go some of them are other stuff so what we did is we took it and we um re reot the whole application and go uh using service Weaver and this is what the results of the Benchmark was so from just a pure uh lines of code perspective with the service Weaver we have way less code um uh
we literally have zero config code and then we have uh about thousand lines of code less than the actual uh old application um um and then on the micros so the reason why there is less code is because there is no service Discovery so the the application itself because of the service Weaver the service Discovery is built in so all the code which is service Discovery and
trying to figure out where the other micros services are is gone and then on the performance you can see that it's actually performing way better than than than than how it used to be um yeah you have some built inry so I told you about this um uh you have a logger of course that's the default logger in go you have a buil-in open Telemetry you can
just basically uh call the open uh Telemetry agent or the open your library and then we will expose those for you I did already a demo um so yeah so essentially the TDR is service Weaver will allow you to write applications as modular binaries each binary is an interface or each component is interface Implement them do all the service Discovery deploy them as single binary deploy them
as multiple binary um uh and and um yeah then you don't have to do service Discovery you don't have to write code for uh containers for yaml for kubernetes for all that stuff this is what we're working on um we are working on multilanguage support we want to extend service we beyond go um and the language we're looking at right now is rust uh that's because I
like rust and uh because why not right um doing some better uh performance improvements we're like working on some um extra just like tweaking for for the underlying um uh performance itself and of course because everybody is doing gen we're doing also some gen stuff and yeah that's it that's all I have I hope this was useful I know I've been all over the place um uh
if you have any feedback scan this QR code and send it to us and that's the email um and that's a website service we Dev um if you want to try it out and uh yeah that's it thank you very much I hope useful thank you how much time do I have five minutes yeah okay uh we currently don't have any questions any questions from the audience
either this was useful or no one understood what the I was talking about for the last 35 minutes so did anybody learn anything new today from this oh cool cool most of you good good okay yeah thanks up no worries thank you very much thanks for the demos and we are looking forward to dig into this thank you thank you very much
More from this event
See all 73 talks →
Tomas Lekavicius: Building Tech Product Offer
42:08
Alisa Dammer: Science and Tech Backed Approach to Increase Productivity
44:53
Roy Wasse: The Definitive Answer to Measuring Developer Productivity
44:47
Pierluigi Meloni: You’re a Great Coder? That Alone Won’t Get You Far
44:47