SF Scala: Alexander Kops, Scala at Zalando
Recording: SF Scala: Alexander Kops, Scala at Zalando
okay thank you again for for having me so the name of the stock is Scala Microsoft's at the biggest tech company you've probably never heard of so it's about zalando and how many people have heard of the company's the land before you read about this talk I've Kenya one two three all three people for all right so most most of you didn't and this is also my experience and talking to americans especially because yeah we're european company and today i want to talk to you about what the salon de does and how it comes that we do micro services and why we are using scala and how are you using it this is me hopefully i'm still looking like in that picture i'm a delivery eat at zalando that basically means i overlooked for five teams now like a technical lead not a people eat and my department is brent solutions and we are basically doing the BTB side of cylinders all the world people put their products in and cater for the brands like adidas nike and so on and i'm at zalando since 2010 excuse me be sure I was a wonderful um we could put it in sync we actually had recently we had like five people from from the London in the catalog actually I'm was not too fancy apparently so they chose other ones but maybe next round I don't know yeah that's about me so when I started when I joined the company actually it was founded in 2008 only like so we are now seven years old I don't know if it still count as a start-up I know probably not a few see the size so that those two people a robot and ovid founded in 2008 i joined to the intended was so much fun 40 people back then so very very start a peep definitely i was hired as a PHP engineer back in the day and you can see we've come a long way now i'm doing scala and giving a talk about it so yeah so what that's the land i actually do so we are a fashion e-commerce company as when you think of Zappos here in the US so something similar for Europe we are basically you can make it by as you can shop clothing shoes and so on with us and we currently our biggest challenges we're going from a traditional me buy clothing model to we become a platform so other people can sell their stuff on our platform so this is really a big thing for us because we need to open up everything whole platform to to allow other people to use it so as I said seven years but in that time we've grown fairly quickly and it was very big as you can see in those numbers we shipped to 15 countries in Europe so that's probably why most Americans don't know is we only cater for the European market and 60 million customers 8,000 employees and some or 9,000 even see how to keep up with the numbers so in tech we are right now about 800 people and we have big plans and growing too through two thousand engineers in the next year he had just because of this platform thing I mentioned it's a big undertaking and we need lot of people yeah last last year we went to stock market as well so probably doesn't count as startup anymore here a few numbers about our tech development as I said 2010 when I was started we still using magento I don't know how many people you know that it's I guess it was a good way to start because yeah when you started startup you never know if it will be successful or not so we took something out of the box like magento and but even the 2010 it didn't scale anymore so we patched and Patrick patched and it couldn't keep up with a gross so in 2010 we did a big weave right in three and a half months we rewrote everything to a Java stack this really completely completely through the whole thing away and replaced it with in you something you probably only can do when you're a very young company so and in the next year's up to this year we were massively growing with this stack but then we saw basically we added keep Adam adding more engineers and it didn't really the pace didn't keep up in the same same way and that was a was kind of kind of a problem so to get these two thousand people we also scale out a bit more into Europe so we have basically berlin-based originally we open up tech ops in dortmund my hometown back when King lot but Alfred and now also double in Helsinki so we're kind of growing internationally as well so Dublin is our fashion inside centre lots of data science this stuff going on I guess they're trying to figure out how how to find out if ever page on the internet is talking about fashion and mapping that to to depeche main things like this housing Keys our mobile app said just adding people didn't scale up and the amount of innovation we had so adding more people at added more complexity and that's why we started this year i clear only in march or april i meant not completely sure and prevent our complete model of how we do IT and that's where it starts to become interesting form for muscala perspective because instead of this classical director model we turned around the ed ho teka organization and basically made our team's autonomous so we don't have this top-down model anymore way you have like a team lead to saying what you have to do but the teams are basically the top class entity in our organization and they can choose which technology they want to use for their stuff how they want to work together and so on so that's where we really started to open up or old fixed extech only Java and only postgres to stop procedures it was even back in the dana marie the modern and innovative but it worked well enough there i wrote a lot of pl/sql codon in my time let's see and yeah these are the three pillars I don't know some of you might tell another the book drive Daniel Pink's is based on this we believe that people need to know the purpose of what they're doing then they have like in the motivation to to actually do their best and they need mastery to do that so we actually investing a lot of time into that into bringing people making people good in that what what they're doing and I want to do and of course autonomy as said teams can do can choose this stuff they want to work in and that fits the purpose of this so this this was basically the starting position and beginning of this year where we actually looked into other technologies and I opened up our old stack and well hey actually able to look left and right what what what other things are they emphasize Java and the stuffy no sorry whoops something my head headlines split up it's just sort of play we also so we have autonomy now great everyone can do whatever they want so it's also a recipe for catastrophe so to you have to have some rules of play too so that everyone runs in and around and the sweet stuff so you have to have some some contract on on what we're doing right so basically everything we are doing in the future but really every piece of software way of writing in the future needs to stick to these rules of playing basically and that's where the micro services come in so previously we have yeah monolithic and can say that this a lot of java model is talking with soap to each other and the worst offender in this case is our shop so the thing that the customers see when they type in the land o de or zalando UK or something the shop team all in all it's like 80 people and they're working on a single code base and can imagine that that really slowed down development and innovation and the frustration got bigger in the developers so basically what we're saying right now whatever everyone is saying probably a way to go for us definitely is to go to Microsoft's rod so build single services that do one thing and one thing right and that I loosely coupled but to have a speak this the same language we stick to rest api's and we have even a more strict approach to that we have rest api is but we also were api first that means before you even start writing your micro service you basically have to line out what the API looks like so we chose swagger you probably have heard of swagger it's a format which you can describe your API so which entities which end points so I developers us to write write a swagger document first how the the service will look like we have a little API guilt of more seasoned developers who take a look and the goal is basically that every rest api we have should look as if the same developer has has designed it so not like a variety of a vaporizer but really something that looks the same this is really the only point where we are very strict other than behind what's what's going on behind your API that's up to you basically and software-as-a-service principle just means you should write every every micro servers or every service you buy it should be thought of as you can give it out to any user party to use it physically so that means we don't have internet shows anymore by definition every single service sits there on the internet with the rest interface at the only thing that prevents people from using is is our authentication which then handles all the Scopes and so on and yeah last thing we are we have we are coming from a very traditional data center we have two data centers right now we're all the legacy stuff is going but to enable the teams to actually write their own stuff and be innovative we gave every single team in AWS yeah they own the AWS account so they can enter and responsible for the stuff they're right so basically programming it no QA they have to do it themselves they have to run it have to operate it if it breaks in the middle of the night there we go responsible for fixing it so this is a high motivation for everyone to invest in their quality and so on so that makes it made it actually possible for every team to choose their stack there I won't you want to develop and so that doesn't mean we're going all scala now but actually a large part and since it's kind of yeah how to get an oversight right now because right now it's really starting to to run off people that run over by noosa new things we had to to grasp which teams are actually doing scala which app which teams I using what technology so I set up a survey and send it around in our scholar guilds to actually figure out with which teams are actually using SCADA so and you see basically the results so first of all forty percent of all our engineers have pointed out they want to learn Scala as part of the two of mastery so there's a high demand high interest in in our developers that actually want to read gallon and for that we have like four certified trainers typesafe certified trainers you can do internally the scholar and and play and workshops so I'm one of them and right now we all have already over 12 teams and that are developing the Micra services are the new services all its gala and mostly play so I guess few of them you're using spray at i/o and most of them I using play for their rest services so that counts like 440 engineers already and we have only started quite recently as you sec so i won't be able to tell you any kind of like metal stories about them what what you should do what went wrong so I Riley right I did the liftoff face so I've listened to a talk from guilt and the other day they are basically they're like two years I had to have while I turned eighteen microservices and everything is running but I think an exciting time with has started at the lander so basically now you can feel all the innovation it coming out people that just eager to try out new stuff and mel's gala is one of the one of the hot topics right now in the company and what we've already seen is that at least the code base of our Microsoft's is that I already already developed it's like Scala Mike reserves thirty percent of code of all the other serves you would see in Java for example and it plays very well with with all the legacy stuff we have all kinds of Java libraries there's Java soap clients we unfortunately to speak to the legacy services still and until we've coming full I WS and full microservice but now it was it plays very well long and people are very excited to go that way so it was already almost it so we had here a few example occasions that that are using already scala home Merchant Center that's basically my my teams that are doing that is a sore center where again where people can login to put their products onto our platform this already couple of services all written in Scala and they use spray I couldn't I couldn't talk them into the play and why and we have fraud analysis of web analytics to further this is a spark by the way and a be teasing to payment services or broad variety of all kind of a kind of front-end services that are currently in the way of being developed in Scala actually so and from those things only two are actually in production the rest is currently in in the makes of C so very exciting times ahead from es at least as escala phonetic nor I would say I like scholar in richmond and one one thing i want to mention this is an initiative that we started together with type save i mentioned the api first approach before so that means i said every team has to write for each service and an api document a swagger document before they start doing it and we are currently developing a library so to developers in house i doing it and together with James Robert their technique for play framework like a play library which basically consumes this swagger definition and generates the other stuff you need like two controllers the router even case classes so that you need for the for the resources for you and you can already see it on github and it's in a prototype phase right now I mean I wouldn't use it in production yet but you can of course use it and someplace to rest me I'm guilty at liking scholar so check it out on github so we also pick on episodes right now and we have lots of stuff and github and one of them is our place so I go library so if you use swagger or I interest in the API first approach give it a try give feedback to some of our developers question yeah is that like a build step generator play stuff or is it run timing let's repeat the question okay I think your question was if it's a one time thing or is it a generator of for your code yeah so basically it's it's not run time it generates stuff for you but it generated in a way that you devote over right to your existing implementations so basically generates trades and the rotting file and stuff you add to it then won't be destroyed so you can rerun it if you change your swag of file so was it yeah it's a runtime magic because it is yeah way more complicated okay that was it or it was all ready for my a short talk thank you google so i'll be around for Walker if we can do the restaurant but I will be rounding together with vodka and Lori so Lori's also American can't talk American English with her but we had German English like with me follow us on our tech page we have a block with kind of interesting topics they've come all the time a Twitter and of course our github page and yeah I know other questions around here yes simcha agendas dark to metro socius also like API first do you do feel the main benefit out for tending to the tab is coming from oh it's coming from the rest api or the API first this swimming did so so if anna silicate correctly if the main drive to change comes from from such discala to see the benefit come from its many from changing to the programming language from java to sagada o is for the play or it so come in from metro bus leading to the metro services oh yeah so the main benefit for the company's definitely switched to to the microsomes approach because for that we make a development process we're very greedy couple of days it's not like it's a shop team with the 80 people somebody has to wait for someone else in this model is to fix stuff before we can deploy we can have individual components and Scala is only a nice benefit for us because if people like the length like me like the language and more productive in it I can choose it and be more productive in building the micros but really the main point or the main benefit for us is definitely just move to micro services education yes we basically and dimension we have cause to ever you ever mined every service needs to accept was two tokens and we have if you know the Fort Rock and this is an old son authentication open source thing that was now just now company called for you have to access Titus personal contacts yeah with with that with that alters eight so with that token basically comes also the scope of what that person or the service of this can access so basically with with that scope a paradigm we are securing our endpoints and only people with the right totaling that has the scopes to access this resource can let you do it and in case Derek as a customer and gets it was talking we just pass it on to the other down the line so we be we act on on behalf of that customer then I I don't know was first so we have three okay maybe you and then doing it you it's okay the question was about how we manage the deployment and multiple versions so we have as I said yet every team has their own AWS account so do it via team deploys and we have written like a little tool set around our deployment it's called stops that I hope you can look at that is basically our deployment artifact is a docker container so basically when you build something and pack it in it in a docker container we brought their own and talk a registry that doesn't allow to overwrite versions like the original registry so Becky that thing is 10 version and you tell our tooling to deploy this version of the docker image to AWS and basically we do you have a mechanism that does like blue green deployments basically so you deploy a new version it's in the load balancer that has 0% of the traffic so you can do like smoke checking and so on smoke tests on it and if or maybe even round ten percent traffic to it to see if any arrows come up and then switch all the traffic is view version and if you need to do roll back you can do the same thing in reverse again yes so possibly deploy can gradually switch and then you have always two versions somehow running but only one is in the end getting the traffic and but you can roll back and also deploy new versions but it at any given time there should be only one version running the other question will be and those specially for science has shown in equation that's a good question so first of all how long would it take to switch this kind of yeah I I don't know I'm not like can read the future but I hope we hope that we at least can move to AWS within two or three years it could also mean we just move our legacy systems into the cloud that doesn't mean we already finished like splitting up into microservices I think this is this also depends so I think our approach right now is to have news new things as Microsoft's is first the only exceptions are shop as I mentioned this is a really big one and for that we do be doing rewrites so basically we post will pause the the feature development for that and then big to big effort but for the rest of it is more gradual process so new features will go over and if if there's major changes in the legacy code then we will probably also put up a new Micra so so will be like a gradual change not like a big bang so now everything is smooth to make services and the other one was transactional handling right so I I don't know that yet but I think projectional you you can can do transaction over Microsoft's very bellows you have to that would be like hard thing to do so yeah basically have to take care of it in your application and it lines so that when you see that there's some some harrow that there it will be like a the rollback mechanism so there's no fancy je a je senior source or transaction over services but yeah I don't know yet to be we don't are not there yet where we had replace a problem that could be sold for transaction handling but yeah as far as I know now you have to basically know that there is no transaction handing over some calls and do the failure case yourself and he was yeah see spending what this gentleman was asking before so with regard to data to segregate it is your data across the micro services and do you find it summer time when you have great one microservice you morph some data you travel you step over and the toes of another man uses it's also a question so basically what the question was about terms of data that that's microservices might touch the same data and then we have it in two places so understand correctly it's also a bit early to answer that for me because currently is all the data is still in the legacy serves but and my idea would be that it's as soon as so you should should cut your Microsoft as really as in on resource level that each rank services caters for one resource and if you might have something took the kid I don't know yet but and I think yes if you keep your mic service really really dumb down and resource for a sauce and hopefully you won't have too much problems but I haven't been there yet so I can really give advice on that yet hmm that's where the devil is and okay so look out for that and next year come back and say why we don't do micros anymore you break up your largest distributor smaller services did you find that you had common boilerplate and if you do do you have like an internal library that shares across all these services i just had people repeat patterns of course so when for example at least four come to yours stuff is something that you will need in every year service so of course we one principle we have is win when we have shared code between libraries or between services we need to cut it out and make it home source so basically and you have a very high visibility of that thing and of course there will be a I guess there will be a lot of libraries coming out of this process to basically cater for the boilerplate stuff so play framework handles a lot of it for example but some something like authentication or some suffer or deployment process like logging integration with I think we'll be using lock entries or on your elegance and this stuff is in every Microsoft's and we probably like figure out one library that will be on github alright no other hands opened and I would thank you for the invitation for listening to me and then we'll listen to Conrad next you