Chris Richardson, Q&A with Alexy Khrabrov of SF Scala @Sungevity 20150224

Chris Richardson, Q&A with Alexy Khrabrov of SF Scala @Sungevity 20150224

Recording: Chris Richardson, Q&A with Alexy Khrabrov of SF Scala @Sungevity 20150224

foreign developer series and we are on location in Oakland at sungevity for a meet-up with folks including Chris Richardson and he is here with us hi Chris hi how's it going good good to have you with us so Chris is going to talk about microservices and even sourcing but Chris is known as the one of the founders of cloud Foundry and I wanted to ask you about about the history and where is cloud Foundry now and basically maybe you can give us a little background for uh to understand Canfield trajectory in technology sure well I should begin by clarifying it's actually the I created the original cloud Foundry which is different technology to the one that exists today but you know the history goes all the way back to I think it was October 2006 and an Amazon evangelist came to speak at the Oakland Java users group and we thought he was going to talk about apis for buying books because this was like part of a series of talks on while web services but instead of a book apis it was Amazon ec2 and I think sqs and S3 and it was like wow you can rent servers by the hour for and pay 10 cents an hour mine was blown so I signed up for the beta program which I got access to 2007. and that turned into an open source project Cloud tools which evolved into the original cloud Foundry which was a Java paths for deploying Java applications on Amazon ec2 so pretty much it just automated how I was used to deploying apps for for clients so with just like 11 clicks of the mouse it would upload your War file and spin up a bunch of ec2 instances configure Apache as a load balancer launch one or more Tomcat instances and also set up MySQL with Master slaver application as well so it's just automating what what I was what I'd done many times before why 11 clicks why why not one click well you had to make you yeah I think yeah I mean basically you there were choices you had to make one click was pattern by Amazon so instead of one it was one one right right so this is actually that's very interesting because it's early days I was actually at Amazon when Amazon was started and it was not yet clear how people can use it so you're actually one of the early uh yeah I mean it's sort of you look back and it was this obscure thing right you know ec2 what the heck is that right and I don't even know if the term cloud computing existed back then and right suddenly womp and then you know then there was all these like Cloud camps where people sat around and discussed what's the meaning of cloud computing right that's right in the end I just got fed up with that and I just decided I like AWS I don't care what you label it but it's useful and yeah so now you know given this history the microservices interest actually Focus right because it's kind of it to me it seems very logical stemming from from that but maybe you can kind of say for yourself how how did you arrive at this interest in microservices you presented that last year uh scholar by the Bay well I think that there's a certain inevitability that if you build a cartilage complex enough application you're going to want to adopt a service quote a service oriented lowercase architecture right and in other words microservices because a complex monolithic application is just too much of a headache and you know I think when I give talks there's always people in the crowd who have to deal with large complex monolithic applications and it's incredibly painful for them right so so it's just sort of a natural evolutionary step that you want to have in what's what's now called a microservice architecture when I think that and unfortunately I'd much rather it be called a service oriented architecture um because microservices places too much emphasis on micro and not enough on services but the trouble with service oriented architecture is that it just has way too much baggage associated with it right yeah like will the Ws star and esbs and all that kind of kind well crap basically so why are we going to go from microservices to melee services like how much weight should we put on micro and how do we Define that because different people mean different things yeah one source of inspiration for me that was this book The Art of scalability and in the book they have the scale queue um with three-dimensional model for scaling applications and and what what they call y-axis scaling goes by the name of functional decomposition which is basically just breaking up your app by function um in some sort of meaningful way and that that to me is what microservices is all about functional decomposition of your app and you do it in order to solve problems around development and deployment and scaling and as opposed to just doing it for the sake of having lots of small services so basically I see so micro in your uh sounds would mean kind of logical logically separate orthogonal service which can be composed with other services yeah but but only break things up enough to solve problems not not just because you've got the micro service religion okay so another thing you do is spring and so I want to crawl spring and call Foundry fit together and basically what's the relationship of all of those to the cloud Foundry exists today with with pivotal oh well so if you think about a microservice application there's a lot of moving Parts whereas before you could just take your one large War file copy it onto tomcat and and maybe multiple Tomcats And you had a running app whereas now if we've got multiple services in each of those Services need to be replicated for availability and throughput you've got an awful lot of moving parts and so you need some level of Automation in order to make your make deployment sort of practical and so one answer to that is obviously a path such as Cloud Foundry another answer actually is some of the docker clustering technology like kubernetes or Marathon or you know anything that sort of automates clustering of things and has built-in support for dark ratings kind of quite a powerful deployment option but the key is automation yes um and then you're asking about spring um yeah it's funny right I've been using spring for a really long time like I guess since 2004 and what's remarkable I mean it's kind of weird this is a Scala Meetup where you're obligated to sort of hate Spring right absolutely yeah you can really dislike it um but to me spring has just continued to remain incredibly relevant and in particular there's this technology spring boot that provides sort of a framework for building or opinionated framework that lets you very quickly get a spring application off up and running and it's such a great fit for microservices where because you're constantly building new applications and with spring Boot and its convention over configuration approach you can very quickly get a spin up an application that's got health checks um and you know a whole bunch of sort of production-ready features at that point okay let's go to know and so in both the call Foundry as it exists today what is the uh kind of relation to the original cloud Foundry you created oh I mean those two things I mean they're very very different I mean in the past that I built was specifically it was very simple right it was just Java apps on ec2 whereas Cloud Foundry is much more elaborate multiple languages many services gigantic open source Community um so the only connection effectively is the name at this point okay which which makes my wife very excited because she's the one who came up with the name no this is a great thing right like name you know as Pro commercial all names are important yeah so that's absolutely so she constantly reminds me that it hadn't you know her her naming lives on yes but also I think the open source approach is similar right the the focus on open source well my part of what I did with the original cloud Foundry the cloud tools provisioning layer which was sort of a CLI based approach approach the deployment was open source but all of the higher level stuff was not actually open source okay so but I mean definitely we you know now with the open source approach pivotal just announced a strata I think you know it's great to see this open source platform right yeah for applications yeah interesting so and I know that you recently got interested in event sourcing architectures and I'm really curious about the connection you see between event sourcing and microservices oh yeah so I think so if you look at modern Trends in application development so obviously microservices is one part of it and so what you end up with when you use microservices is a bunch of services each one with their own independent database and then also if you look at the I mean another big Trend in that app development is no SQL right and once again you end up where you sort of at your polyglot persistence in general where you end up with multiple databases most of which have very sort of limited transactional capabilities um so that you end up in both microservices and those SQL with these distributed data management challenges of needing to have transactions that span multiple databases yet you do not have two-phase Commit right cap theorem and and just it's complete you know it's out of fashion and so the solution to that is an event-driven architecture where things publish events well when State changes in one service it publishes events and subscribers can consume those events and update their own State and Implement consistency and it turns out that event sourcing is a very good way of implementing an event-driven architecture yes but you know we actually implemented an event sourcing architecture adversal uh a couple years ago and we actually ran into this problem that for event sourcing you do need transactions because you need serialization of events if that or at least within some context right because if you're updating a data structure you know you basically read and write to it you need to know what is the order of reason right so we actually end up using an abstraction of of an event log which then we Implement using MySQL because we needed transactional capabilities so we we found that basically if you if you have this notion of a login sequence and you need in this case we need transactional database to implement to actually ensure that we'll have the thing so you so you might publish this event but the question is how you're gonna at some point you you will need some transactional capability to to establish the order yes but I mean one of the things I've been working on is an event store that actually takes care of some of that hard stuff ah okay um and so they're sort of inside it there's sort of a transaction Manager Management kind of capability that that um enables you to atomically persist events and publish them at the same time okay okay now this is great so basically we are actually working on a very similar problems yeah I'm very very excited to see you work on this cool um so and another thing you are the organizer for the East Bay Java user group and I was you know very happy to find that you guys run uh events not far from from where I live as longevity so this is you know and obviously so this is a joint event with uh is by jargon and as a scholar and you're a long time Jama user so I wonder you know what aspects of Scala uh interest you the most how do you see you know scholar Community evolve and basically where do you see skull Community going in the future yeah so it's interesting so the Oakland Java users group has been meeting since 2003. wow so kind of kind of a while yeah um and we're still going strong so so um so if I you know I look back and interestingly the the the the core part of the original cloud Foundry was implemented in groovy right and the reason I like groovy is that it's a very expressive language right you've sort of got some kind of functional capabilities where you can sort of map over Collections and filter and that kind of thing um so I I love the expressivity of groovy well the expressiveness rather of groovy but then I got very frustrated by Dynamic typing I you know I should have written more tests I know that but but basically when you have to execute your code in order to find typos that's really frustrating right and there were a few especially when some of the tests even launch an ec2 instance and then fail right that's a you know that that process back then took many minutes and so I wanted an expressive language with static typing and so I think it was back in 2009 2008 I discovered Scala and got very excited by it um and you know to this day I I still quite like Scarlet though I'm somewhat frustrated by the slow compilation times and the slow ID and and this quality of the Ides do you still write job as well only when I have to okay I find it very frustrating actually it's sort of you know give you an example so for the event sourcing stuff that I did I actually had a scholar and spring example and I thought I'd open it up to a wider audience by having a Java and spring example and the amount of typing that required right like a simple case class in scholar expands out into a whole file of java code with Getters and Setters and it's like I hate this it's frustrating well I mean certainly skull is more concises yes yeah yeah I just love I love the expressiveness of it but then at the same time I actually got to use a Java IDE again and it was like oh yeah this is how an idea how how a really good ide Works yes absolutely well hopefully we'll see much more we already see a lot of progress and we'll see a little more of it well this is great stuff Chris so we're looking forward to your talking it's great to have you in the community it's great around these joint events and I hope we'll run more events like this in Auckland yeah same here thank you thanks foreign