There is a cost associated with larger code base. Cognitive cost that translates into a time and monetary cost.
7 years ago
The business case for microservices.
7 years ago
New talk. Ian Cooper from Huddle.
7 years ago
7 years ago
7 years ago
7 years ago
Sounds crystal clear.
7 years ago
Chapel is apparently a language, good for number crunching. This is calculating pi.
7 years ago
7 years ago
7 years ago
7 years ago
Are microservices just actors or active objects.
7 years ago
Pi as a service in python.
7 years ago
Flow is made up of these.
7 years ago
Structure your microservices as 1-dimensional data flow pipelines.
7 years ago
Why does it take so many lines to run a sub process... Because it's 1992, that's why.
7 years ago
Microservices should do one thing and do it well, just like Unix philosophy. Well, actually not true, even in Unix, one tool can do multiple related things.
7 years ago
Russel Winder. Looks like a fun guy.
7 years ago
Lol. New talk on architecture.
7 years ago
You have to trust Marathon to run things in the right places. You lose some control, but it looks very powerful and convenient with configuration for handling recovery, upgrades, dependencies etc.
7 years ago
Like this, and so on. I'm not going to post all of this. I'm sure there are good resources online.
7 years ago
Marathon offers a REST API for application resource management.
7 years ago
Mesos abstracts away your resources and boxes I think. Used in Apple, Airbnb, Netflix.
7 years ago
Not using any of these but I suspect we have developed our own solutions to the same problems in house.
7 years ago
This is true too.
7 years ago
Not an exhaustive list, but it'll help. I can definitely agree with automation.
7 years ago
Now all the complexities in your application are exposed. And possibly public.
7 years ago
And after?
7 years ago
New talk. Conduct your microservices. Before?
7 years ago
Summary: build your public API with care.
7 years ago
Developer philosophy at #muCon2015
7 years ago
We can apply UX concept to API design.
7 years ago
Understand your developer users. Who are they and what to they need. Do they still use SOAP, for example :-)
7 years ago
So this is about external APIs, why should you expose an API and why should you make it lovable. One reason is because devs will evangelise your product.
7 years ago
Looks like I'll have to wait for the guitar solo.
7 years ago
Back from lunch and this is already looking exciting. #muCon2015
7 years ago
Lunch! Kinda strange, but I like it.
7 years ago
Summary: Maybe checkout Swagger and RAML, but this talk didn't do much more than take a cursory look at the different options. RAML could have more tools for node.
7 years ago
API Blueprint uses markdown to specify your API spec, for some reason.
7 years ago
RAML API Designer. Very similar to Swagger.
7 years ago
Swagger in use.
7 years ago
He seems to be pointing us toward Swagger.
7 years ago
7 years ago
7 years ago
These are the full featured API tools he's been using.
7 years ago
What we want in a documentation tool. Using a tool also encourages you to think about all these things. I also like the idea if these extra features too.
7 years ago
The zen of REST API documentation.
7 years ago
Summary: The end reality is a lot more involved than a simple docker container. #muCon2015
7 years ago
Or better yet, use splunk.
7 years ago
Monitoring and logging for hundreds of services. This needs to be collected, aggregated and stored for analysis (ES or kibana).
7 years ago
And now for inter service communication. He's advocating etcd over zookeeper for service discovery.
7 years ago
I wish this guy would put words next to the logos. Docker swarm?
7 years ago
And then that all goes into AWS, right? After 100 clicks and two days, it's all up there. But then you want a staging and integration environments. With a handful of tools, they automated the process. But what about horizontal scaling?
7 years ago
Just put it all in docker, right?
7 years ago
This looks promising.
7 years ago
Summary: I'll have to go over the slides again, but this event driven microservices architecture is worth looking into.
7 years ago
Vertical point of view vs the horizontal. We can test this by looking at the data that goes in and out between these streams. Don't test the process, but the data.
7 years ago
Flow oriented microservices is an events based approach that models how people/clients think about their application logic.
7 years ago
Docker-compose makes another appearance.
7 years ago
Or create entire mock processes, which is a lot bigger to sort out.
7 years ago
Options for doing mockist TDD with microservices. You can create client libraries to mock out your other services.
7 years ago
The London school of TDD (mocking TDD) tests the communication between dependencies, rather than the result. This ties in nicely with microservices.
7 years ago
Manual testers have a hard job, and they don't get enough respect. It's a tough job. #muCon2015
7 years ago
We use the network as a boundary between microservices, and the network hates you. #muCon2015
7 years ago
7 years ago
What is architecture vs design. There are limitless designs, but only a few architectures. Architecture is your philosophy, it's the route you take, the tools you use to find a design to solve your problem.
7 years ago
Nobody can agree. But there are a couple of things everyone agrees on. Isolation and aspiration. Isolation of contexts/functionality/responsibilities and the aspiration that things will be better if we can just get this right.
7 years ago
7 years ago
This looks familiar.
7 years ago
Summary: I'm not into Spring and didn't really get into this talk :-P
7 years ago
Stubbing out services to get started.
7 years ago
This talk seems quite Spring focused, which is fine, but not really my area.
7 years ago
Docker-compose looks useful.
7 years ago
Next talk.
7 years ago
Summary: Microservices are nothing new. We do them wrong a lot if the time. And you don't always need them. We also got some good advice :-)
7 years ago
7 years ago
Why 300?! Size is irrelevant says the presenter. You should be focused on cohesion, does the code belong together. Might as well ask how big an object should be. Think about it in terms of rewritablitity, could you rewrite it in a month. This tends to lead you reasonable service boundaries. Don't be afraid to burn to the ground and start again.
7 years ago
Debugging is tough in microservice architecture. Bit we gain independent scaling, independent failures.
7 years ago
Book to read "Why computers stop" by Jim Reed I think. Talking about independent failures that microservices allow. Although many of us are still building monoliths when we think we are building microservices.
7 years ago
Until you have to.
7 years ago
Keep it single threaded, that's convenient for node.
7 years ago
HTTP is for communication with clients, events are for talking between services.
7 years ago
The central conceit of microservices is an idea that goes back to the 70s.
7 years ago
Open VMS is an OS that was about 2 or 3 decades ahead of it's time. #mucon2015
7 years ago
What we are missing in a monolith is independent deployment.
7 years ago
Developers are good at writing monoliths. We know how to write monoliths.
7 years ago
7 years ago
Most successful software is a big ball of mud. Apparently there is a paper you can read on this.