 Thanks, so I guess that everybody can hear me. Well, so let's get to this. So like I I'm Michael, I'm from I work at Intel Technology, Poland And I'm going to talk to you about Microservices yet another talk about microservices, but with a Specific kind of a use case with that from the service and it will be kind of an opinionated. I won't I won't be showing you anything asynchronous Basically plain old HTTP, but in a cloud So about me like I said, I Work at Intel. I'm a developer and I totally the small team I now I do backend services, but I did Many other projects like I did hardware cryptography in C++. I Work with Java, Android, so Python isn't my Main technology that I use at work But it's my favorite and I think that I'm best with Python and I hope that I will be doing it more and It's my first time presenting my first Python conference my First thanks and one thing I'd like to thank Isabella Izinska So thanks, you know because she helped me with some of the things that I'm going to talk about So I will just give a quick rundown of what microservices are what platform as a service is I'm going to show you the ingredients of I know well so of a successful microservice project Because it's really easy to get them hard like you probably already heard on other talks by the way Talk about Namiko was good. You should totally see that They have only different Points to make but I definitely recommend that because I won't be talking much about philosophy of my services and this is basically The middle part of what you need to know because first thing to get into my microservices Know what they get you then you need to implement them and the stuff that I'm going to talk about today will help you with that And of course we're gonna be using Python tools and other stuff so basically Microsoft service is a small small is a vague term It can be 50 lines of code. It can be 5,000 lines of code. Basically. It has to do one thing well and Their main purpose is to scale well. That's why they were introduced and They are somewhat about people because if you do a big project and you work on a monolithic service In a 50% team is gone It's not gonna go well and with microservice you can split this Into you know into chunks that basically can be processed by small teams of people and that's really good like software development is done by humans and One thing that you maybe didn't that maybe didn't Wasn't touched on other talks There is The set of principles how you do microservices how you design them and it's called the 12 after app It's done by people at heroku And basically those principles are stuff like that the service needs to be configured to environment variables It has to be stateless. So any state needs to be kept in a separate Service like but like a database or a MongoDB. So no SQL base or anything and No, like we have some pretty good success stories like Netflix is based on microservices and there have the 20% of internet traffic is Netflix. So they can be done, right and they can work although It's hard About platform as a service of course, of course the cloud service basically in which the smallest unit that you think about is the app in Normal like AWS Infrastructure as a service you think about VMs like the whole operating system here. You think in the terms of the app and What? You know and you get some you know stuff around it some flavor basically Passes should help you with logging when with connecting services with infrastructure with routing Connecting things together and stuff like that. It's you know, so you don't have to worry about deployments and all that kind of stuff this nice This basically how it looks like No overview you have your infrastructure at the bottom. We are using AWS and open stack Of course those are you know Virtual machines can be bare metal Over that you have our pass we are using Cloud Fungi The past you know, it's It's many machines But it's kind of seen as you know one resources Resource you just have your machines your your RAM your disk space you don't you aren't aware that how many machines are there and Pass round runs containers and within those containers finally you have your apps your micro services and besides that on your Cloud instance, you can have other stuff and services like CD8 which is cloud era how do deployment lock search with which I will be talking about later and basically all the other stuff stuff that your apps can use but those kind of Outside services are too heavy to be run within one container like a massive cluster of Elastic sets you can't run that run that within a Docker container and and when you do micro service on pass basically you Make everything better. It seems like the way to go. So the features of micro services are a kind of strengthened and It really makes it easy to scale basically you can just Write one comment on in common line interface to scale up my app like I need five more instances Okay done, and it's good and if you do Everything right it can be really manageable. You don't need you aren't supposed to need many people and it's Scannings is really easy and you know, you can adapt really fast like you can change your code behavior of your Environment fast not like with a much more logic service that any change requires you to you know to get your three old oldest Developers and think about it for a month because you know, it's everything is hardwired But of course there are not a single bullet not a golden hammer If you don't have a matter Organization you're gonna suffer really really much Even though we think we had a mature organization like professionals But we kind of took them lightly and don't do that seriously like You write your first up Play with a bit and then you set up your continuous delivery everything that I will talk about And of course, you know, not everybody needs micro services Of course this communications overheads because of my Network communication traffic basically you don't communicate through processes through pipes Or within an applications memory. Everything goes over the network and Of course the platform as a service Think also has its performance overhead because you need to run the container you need to manage the games a little bit more and Supposedly it's best to start with a monolith first and then let's put some stuff out of it into micro service gradually Supposedly that's what Martin Fowler says, but I also seen Post on his blog from a half a year later that you can start with micro services people are still figuring things out so To have your micro services you need to have some things set up and inform so so rules So basically you need those 12-factor apps. I seriously recommend that you read 12 factor Net it's good practice for even other software You need to have really good tight set of tests and You have you need to have your continuous delivery pipeline You need to have a way to get insight into your platform to gather metrics like response times Is your app even living? Is it working? Correctly you need to have a specific approach to management of your project because it's challenging and you basically need some sort of Platform version but we'll get to that later Maybe there's a wrong slide for you people, but you know, I think it's great for that It's has as many features as everything else comparing in the realm of Backends you can prototype fast and it is good Testing is really easy. You can't mock things as well in Java for example and Python is inherently good with loose couplings and You see that in micro services You need to have a lot of loose coupling this basically how they are done and how they should be done to Good micro services One cool thing Python code can have a deterministic garbage collection and you need to well, you don't need to but it's a good thing because your app has rum Limit and if it goes goes over it Cloud Fungi or other paths like heroku will kill it So it's good to know how big your application will go and you know not be sure if garbage collection moves we're start or not It's really enjoyable language and lots of stuff talking about it, but you could be talking about it as well One thing I was worried about was performance Was worrying if I would get like the you know Basically like ten times hundred times slower Then the other configuration that we are using which is speed spring boot a Java framework on Tomcat I've tried Falcon which I'm going to talk about later and micro whizgy application and I've basically compared them on a virtual machine to core One gig RAM and the results were kind of surprising because they are kind of comparable. I did a test with Jason serializing deserializing and filtering and You see that basically Falcon appears to be a Python app seems to be even a little bit faster. Although spring is more stable You see that Falcon and we micro whizgy has more failures, but this this is supposedly the micro whizgy thing. It's fast, but it can sometimes And I put them under heavy load so are up. I propose to use Falcon, but you don't have to what's good about Falcon It's really fast For a Python framework. It's light. It's really minimalistic and there's no magic in it. You can very easily reason about the code just one just by looking through it and it's good if you have a big team and you have a lot of Lots of technologies like one services in Java one and one one isn't go ones in Python and if you have to go through them and every one of them is written in some exotic framework that basically needs to be Learned like different language, but this isn't good for the team and if you've had some errors It's good to be able to reason about the code and I don't work Of or on Falcon or anything. I just you know liked it This are kind of the bigger example You see that it's so minimalistic that even it explicitly says that request streams like you see in the post and No last Second last line. We have requests stream read. It's so minimalistic that it only give you streams for example to Request body and when you write the response you can also write directly to stream and we can use Python 3 I don't see a reason why We don't all switch to Python 3 for doing stuff like that. That's one cool thing about microservices. You can experiment with your Technology because you're not thinking about what am I gonna do with this with this big monolithic app in a year No, we can basically write it or just throw it out So it's fine to know experiment a little have some fun And now how should your how's your app look like? It's a basic directory structure Standard Python application Although you don't need to actually have a setup by you don't need to package anything because you're just uploading source to the platform So it's not actually not needed. You have your standard standard app code. You have your test code which can have separate requirements file You need to have your service test about which I will talk later. You can have talks Talks is good. I recommend that Then we have those cloud foundry specific files. There's the manifestium which basically tells Calls foundry how to deploy your app. There's the runtime txt It's a version of Python that you want to have in your in your container so three four two seven whatever and see if ignore is like good ignore, but it's It tells cloud foundry what files not to deploy because basically it just Takes the whole directory that you're in and it pushes us to the container and you don't want that This is how my manifestium Looks like that. It's declarative You just specify the name the command that used to run the app when in the container. How much memory? What what build pack to use build packs are basically? Shell scripts that set your app They run pip installed install the dependencies automatically for you and stuff like that you also show what services should be bind services are those External resources there they're all also can be other apps and they when you bind a service It just put puts its configuration in the apps environment. So we can Configure them and connect them more easily and you can have a custom And environment parameters parameters like here. I've used log load to set up my logging and version Which is interpreted by my program. Well, basically version is just a is just a tag. It's good to Know what version of a app you have deployed if you have many environments basically Let's go further continues the delivery. Yeah, there there were talks about it there are resources on the internet and You will have a really really really bad time if you don't do this, right? Basically, you know, you won't know if your apps are working and if you have a network of 20 or so apps You don't know if they are working Who broke them what broke them one of them which of them is actually broken are all of them broken You don't know so you will have many beautiful evenings at at the office figuring this stuff out and looking through logs proposed continuous delivery flow as you can see this basically how it can go just a few commands you clone your repository recursive because when you do code reuse Code reuse isn't cold reuse is dangerous when it comes to microservices because you don't want a lot of coupling But you know sometimes like for your utility code or something like that it's of course, it's pretty useful and I found that it's Maybe not the best but it's one of the ways that you redistribute your dependencies is to Get some modules basically because you don't need packages for the stuff that you put in Cloud Foundry and You can use with that. You also need to You know a hack and init pipe to loads Add sub modules to the Python path, but it works perfectly well Then you run talks which runs your tests your unit. That's your service tests You bump the version up You see that the version was changed Cf push is a command of the Cloud Foundry command line interface which basically takes the manifest takes your app and just puts it in In the platform, then you do some command I know what whatever you want to run end-to-end test Because you should run end-to-end tests after every basically after every commit the new version of the app needs to be deployed your at least staging environment and you want to have test that will run after it and Then you switch CF target is It switches the place in which At which the common line interface points So you have another environment and you should have at least two environments and just push it to production and it's the whole That's the whole whole thing that you need to do so Deployments and continues the delivery can be pretty easy like easy, haha, but pretty simple from the overview if you're using platform as a service After this you have a working new version of your app in production. Yeah now about the tests You of course need to unit test you have a lot of them The greatest coverage you can do when you're using with the ups one cool thing that you have an interface With the interface and you can test your app As a whole almost because you can use the normal with the controllers, but you only need to mock out the external connectors This is how a Falcon test can look like You probably if you want to do Falcon you can get back to it later about another approach to designing your app would be not to use whiskey, but to use some sort of asynchronous like some publisher public subscribe Method, basically you have you know rabbit MQ Kafka. There's this thing called nuts Which is a cloud fancy Q-ing system Messaging system native to Cloud Foundry basically all the logs and all the communication between the parts of Cloud Foundry is done through nuts and you can connect to it and send messages through it and using this kind of thing and kind of make your unit test easier because you just Mock out the you know the consumer mock out the producer and just put stuff in there and see what goes out somewhat simple and Namiko guys do do this basically Okay, but we found that you don't want it about service testing What it is basically you take the whole service the same way It's it runs in in the container in your actual environment And you just put put fakes around it. There's this one service cool tool called Mounted Bank Mounted Bank. It's basically a configurable Light server you can you can configure it by calling some HTTP methods and It's just sets up like stab endpoints that can be used by your service So any interface that service needs to consume you can stab it with mountain mark basically the test looks like that that's you So fake environment, so just put The right environment variables in your environment You run the Mounted Bank process You do some calls to configure it Then you run your app and you call it with that test client and Basically, it's just it is the same the app doesn't know that it is in the cloud It's like the matrix and this gives you a pretty decent degree of confidence that it actually will work and Really important to have that you can't run and to end tests all the time and when you do that when you Want to test everything with end-to-end tests we have a lot of time to get the response is everything working and It's not that cool and both of those kinds of tests unit tests and service tests can be run with talks and There's a specific way you configure talks because It's a specific usage basically you only need one Python version because your app only runs in a one One types of containers and you can specify what those are You don't need packaging so you have to hand the option of keep as this True you also can add there like pilot coverage and everything that you need Basically, it's really cool to have like Only to run your top comment and Your CI knows that the app should work and the developer know that works and it and he He or she gets like full reports on the apps state About test lines. There's this one cool thing that you can use has any one of you heard about swagger Do you know what swagger is? Okay, so this is swagger Uh-huh No, but seriously, it looks more of more life. Yeah, enjoy. Enjoy my one fun picture This is what swagger looks like basically. It's a live API doc. So I really recommended You can you know explore your app even call the call the endpoints so you can it's great for Introducing new people and for giving it to people who want to integrate your services and with swat with swagger you can have a This kind of a flow basically you have your your app on the right and There are some tools that allow you to you to generate swagger docs from your app It's harder for Python because we don't have this starting static typing So and and for testing it's it's better if you have every if you have your API Declaration like description Elsewhere and being independent and person needs to write that manual sadly, but it's not that a lot of work and then when you have those docs you can host them in a On some endpoint and basically just get it the JSON document Describes your appy, but you also can set up the web UI that you saw earlier And you can do some other cool stuff with it. For example, you can Generate a client client for your service from this from this interface Description and use it in tests and use it for other apps and it's cool because you have You really keep your contract under control Nobody messes around with it and when it goes to you if someone, you know makes changes that break the API It will be merely visible about acceptance tests or end-to-end tests They of course need to be done in the stage in the staging environment in your test environment It's best to run them after each comet, but you need to have Fast suits of tests to run them after each comet and this is a hard thing to do Basically, you need to trim your tests and keep the test base small but sometimes maybe you can get Get away with it by running them nightly if you have great service tests and What one important piece of advice Somebody should own end-to-end tests. See everybody should own own end-to-end tests. It's a common good, but somebody needs to you know Facilitate communications between your developers keep everybody in the know About what other people are testing that you avoid to case you avoid making your tests longer Some few few more points It's good to have monitoring of course you can use Zabix you can use What was it called? I forgot no Google monitoring you'll find something good you should monitor both your production and your staging environment because Cloud fancy and all other paths that you maintain by yourself There can be some funny stuff RAM can go out this space can go out Know all kinds of things can happen, but one cool thing that the whole Platform lets it's let's let it be It allows for easy monitoring so It isn't that hard. It's give it gives you a lot of statistics and stuff And what about other thing about monitoring it basically should sometimes run some form of end-to-end test to know keep you in confidence that your Platform is still working because basically maybe someone some developer Logged in and did some bad stuff that he or she shouldn't do About logs and metrics that you get Like I said all apps should log to standard output And those all of the logs are aggregated and basically available as a stream For some consumers and you can do a lot of stuff with them like put them in elk elk is elastic search logs Tashkibana there also was talk about this good talk probably definitely better than mine and log search is cloud scale Deployment of elks touch basically it can aggregate logs from your whole platform from all of your apps all of the platform Components and put them in elastic search so they can be searchable easy and you can visualize they Visualize them with kibana. You can see What went wrong through all of your platform basically if you have some distributed transaction Transaction is a wrong word but an operation that touches. I know 15 apps and something went wrong And you just you can just go to give up tibana show me this place in time and what? error messages got sent by what happened and you'll see that and it's really cool thing to have that it's a really And empowers logging And you can use data series time series database for your real-time metrics for example What are the response times of your apps right now because Cloud Foundry gives you that knowledge You basically to just consume it and do something with it and you can put it in flux DB for example and just Check it visualized put it in a graph somewhere and just you know constantly aware of what your how are your microservices doing if they run fast enough Also like I said, it's about the people and The every app needs to have an owner person who will be responsible for it with the reputation live honor, etc of course One person couldn't do everything alone and you have this pesky hit by a bus syndrome So you need to have an additional person to help that one owner and they have to they need to have a common vision for your whole service and They basically need to know seriously Thoroughly review every change that comes in When you do microservices, you probably have a big team probably people are you know Switching between the teams so you have different styles and somebody needs to keep track of that So you won't end up with a mess But one thing nobody is unquestionable of course, so the new guy that comes in or a group can Have some valid points and you should listen to them And also one cool stuff It's good to have some form of architecture visualization because you have all that services and they have the dependencies Connecting them and it's good to if you're sitting in one room It's good to have like a board and just you know visualize it. If not that you should share some No, you know or whatever last thing platform deployments I Were in the booth later This is stuff that you don't get out of the box and Some people even say that you shouldn't do it because It encourages coupling basically platform deployments customer versioning is something like that that you Have a list of all your apps and their versions and you know what kinds of versions work well with it with each other and This kind of encourages coupling because you expect specific versions to work with the specific versions And you shouldn't have that you should basically should be able to switch everything around to some degree There's still use cases use cases for it. We have use cases because we want to you know like Destroy one instance and just put up another cloud fundy and set everything up We made a custom implementation that has this one big manifest that merges all the other manifests and Analyze the dependencies between the apps and basically Deploys them in the correct order This is Maybe not needed for you, but it's a cool thing to have and one last thing. Oh one last thing about Endpoints I recommend that you use those endpoints with a version in the beginning because if you're gonna you're gonna be changing one thing you don't Want to have to change two things at once and that even the word worse The worst case is to you know You change one up and then you need to change the other one and then use one to switch back And you can because the other one has incompatible changes. So basically use endpoint versioning and You know keep Different generations of your API around for a while so, you know, so everything is fluent and everything is Nicely loosely coupled and you can move your apps around And if you want you have big slide with more links more stuff I really recommend the book in the beginning or I look about my services is good You have some other Python talks that I enjoy that are Somewhat connected to this and that's all that I have for you today Thank you. Michael. Do we have any questions? Hi, that's Mooney or actually or something like that. That's just right So the real question it's been almost a half a year since these makers have this thing explode Feels like a hybrid doesn't quite I have already read the book all the links. I want to the conference But the the end I have this feeling this strange. I cannot even see People really using I mean, obviously, we all know the case of Netflix. For example, they have a hundred Microservices, but it's impossible to see them. They're only in house Do you know any kind of resource where people are putting real the microservice to go to look out? Yeah, there's a problem. There's not many open source I didn't basically there's there are no open source projects yet that use them that It was the same issue with the Namiko presentation There's nothing yet. There's nothing open yet. Sorry Maybe in a year the feeling is like these are people of them that use a design the Namiko is a close company that have their products and that's it but In all the kind of projects that for example Django installation, you can go you can even download the Europe iPhone Don't page and it's there. It's Django application. You can look at it But if the microservices that doesn't seem to be nobody that is really exposing how they are using Yeah, basically, it's a kind of a Know an approach that only just you know gets you know more more widely adopted and It's sad it would have do us much good probably if we had something like that, but suddenly there's nothing yet You talked about writing stats into your microservices and health checks writing sets stats Statistics and health into your microservice Basically, you don't need to write a lot of stuff in you get it out of the box like cloud fungy Keeps the tabs of like the messages that get passed around. This is one one of the reasons why we use HTTP because it's really No, it's visible. You can see all the messages that went between services and Response times of all the messages. So you kind of get that out of the box Your app just writes to standard output like normal logging and you have some of those stuff, you know out of the box, but Okay, you basically answer my question What do you suggest for registering and looking up for microservices Well, I think that Lymph people Have a register. We're not using it exactly because we we like we know what's in our platform And the cloud fungy has this command line interface that basically gives you that You see the apps you can check what app is connected to what other app So you kind of have it out of the box and if you have swagger You see you know that cloud fungy lets you see all the apps and if you have swagger deployed Then you can just go to the end point Within the app with swagger and just look what what's what's it API is And you can you can also like only host the Swagger docs within the apps and you can have another like documentation app that Has all the other apps bound to it like it knows about them and it Combines all of the other docs in like this one global platform API Document live platform Okay, that's all the time we have for West chins if you have any more than we hope will be around So thank you, Michael