kidwellj/findcommonground.uk
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

added axel_schulz to authors.yml

Browse source 
added header to article and fixed md display issues
This commit is contained in:
Axel Schulz 2016-03-12 23:50:02 +01:00
parent 23a8d605e2
commit 2a1dde4717
2 changed files with 32 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
_data/authors.yml
View file

@ -38,3 +38,8 @@ eike_hirsch:
name: Eike Hirsch
email: eike.hirsch@haufe-lexware.com
twitter: stagzta
axel_schulz:
name: Axel Schulz
email: axel.schulz@semigator.de
github: axelschulz
linkedin: luckyguy

13
_posts/2016-03-11-being_a_microservice_or_cattle_over_pets.md
View file

@ -1,3 +1,14 @@
---
layout: post
title: Being a Microservice or Cattle over pets
subtitle: A personal recap on QCon 2016
category: conference
tags: [qcon, microservices, devops]
author: axel_schulz
author_email: axel.schulz@semigator.de
header-img: "images/bg-post.jpg"
---
# Being a Microservice or Cattle over pets
First thing I did after receiving the invitation for QCon 2016 was of course to take a look at the schedule.
@ -44,10 +55,10 @@ Why would I start thinking about, e.g. how to implement Service Discovery or whi
When you're splitting your monolith in two, you have other problem to take care of like how to make sure the two new services still get to communicate with existing other components. How do they get their data, since they were probably doing cross-domain data access before. Where to deploy the services? Same site as before? That might require re-configuration your web server. So solve these problems first and play around with the rest later.
For WIX.com already this first step of splitting the monolith brought significant benefits:
* seperation by product lifecycle brought deployment independence and gave developers the assurance that one change could bring down the whole system (but only half of it)
* separation by service level made it possible to scale independently and optimize the data to their respective use cases (read vs write)
What I particulary liked about this talk was that he showed a real practical methodology, that everybody could follow - literally and practically - and that alignes with the hands-on mentality that you need to have if you're taking on a problem like this.
This not often heard pragmatic approach wrapped up with the ubiquitous remark that each services must be owned by one team and this team has to take on the reponsibility for it (_You build it – you run it!_) frankly did not contain any new insights at all but it served so well as a real life experience that I would really love to try it out myself - watch out Semigator-monolith!