Story

#muCon2015 Day 1

  • 4 years ago
  • 4 years ago
  • 4 years ago
  • 4 years ago
  • 4 years ago
  • 4 years ago
  • 4 years ago
  • There is a cost associated with larger code base. Cognitive cost that translates into a time and monetary cost.
    4 years ago
  • The business case for microservices.
    4 years ago
  • New talk. Ian Cooper from Huddle.
    4 years ago
  • 4 years ago
  • 4 years ago
  • 4 years ago
  • Sounds crystal clear.
    4 years ago
  • Chapel is apparently a language, good for number crunching. This is calculating pi.
    4 years ago
  • 4 years ago
  • 4 years ago
  • 4 years ago
  • Are microservices just actors or active objects.
    4 years ago
  • Pi as a service in python.
    4 years ago
  • Flow is made up of these.
    4 years ago
  • Structure your microservices as 1-dimensional data flow pipelines.
    4 years ago
  • Why does it take so many lines to run a sub process... Because it's 1992, that's why.
    4 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.
    4 years ago
  • Russel Winder. Looks like a fun guy.
    4 years ago
  • Lol. New talk on architecture.
    4 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.
    4 years ago
  • Like this, and so on. I'm not going to post all of this. I'm sure there are good resources online.
    4 years ago
  • Marathon offers a REST API for application resource management.
    4 years ago
  • Mesos abstracts away your resources and boxes I think. Used in Apple, Airbnb, Netflix.
    4 years ago
  • Not using any of these but I suspect we have developed our own solutions to the same problems in house.
    4 years ago
  • This is true too.
    4 years ago
  • Not an exhaustive list, but it'll help. I can definitely agree with automation.
    4 years ago
  • Now all the complexities in your application are exposed. And possibly public.
    4 years ago
  • And after?
    4 years ago
  • New talk. Conduct your microservices. Before?
    4 years ago
  • Summary: build your public API with care.
    4 years ago
  • Developer philosophy at #muCon2015
    4 years ago
  • We can apply UX concept to API design.
    4 years ago
  • Understand your developer users. Who are they and what to they need. Do they still use SOAP, for example :-)
    4 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.
    4 years ago
  • Looks like I'll have to wait for the guitar solo.
    4 years ago
  • Back from lunch and this is already looking exciting. #muCon2015
    4 years ago
  • Lunch! Kinda strange, but I like it.
    4 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.
    4 years ago
  • API Blueprint uses markdown to specify your API spec, for some reason.
    4 years ago
  • RAML API Designer. Very similar to Swagger.
    4 years ago
  • Swagger in use.
    4 years ago
  • He seems to be pointing us toward Swagger.
    4 years ago
  • 4 years ago
  • 4 years ago
  • These are the full featured API tools he's been using.
    4 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.
    4 years ago
  • The zen of REST API documentation.
    4 years ago
  • Summary: The end reality is a lot more involved than a simple docker container. #muCon2015
    4 years ago
  • Or better yet, use splunk.
    4 years ago
  • Monitoring and logging for hundreds of services. This needs to be collected, aggregated and stored for analysis (ES or kibana).
    4 years ago
  • And now for inter service communication. He's advocating etcd over zookeeper for service discovery.
    4 years ago
  • I wish this guy would put words next to the logos. Docker swarm?
    4 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?
    4 years ago
  • Just put it all in docker, right?
    4 years ago
  • This looks promising.
    4 years ago
  • Summary: I'll have to go over the slides again, but this event driven microservices architecture is worth looking into.
    4 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.
    4 years ago
  • Flow oriented microservices is an events based approach that models how people/clients think about their application logic.
    4 years ago
  • Docker-compose makes another appearance.
    4 years ago
  • Or create entire mock processes, which is a lot bigger to sort out.
    4 years ago
  • Options for doing mockist TDD with microservices. You can create client libraries to mock out your other services.
    4 years ago
  • The London school of TDD (mocking TDD) tests the communication between dependencies, rather than the result. This ties in nicely with microservices.
    4 years ago
  • Manual testers have a hard job, and they don't get enough respect. It's a tough job. #muCon2015
    4 years ago
  • We use the network as a boundary between microservices, and the network hates you. #muCon2015
    4 years ago
  • 4 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.
    4 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.
    4 years ago
  • 4 years ago
  • This looks familiar.
    4 years ago
  • Summary: I'm not into Spring and didn't really get into this talk :-P
    4 years ago
  • Stubbing out services to get started.
    4 years ago
  • This talk seems quite Spring focused, which is fine, but not really my area.
    4 years ago
  • Docker-compose looks useful.
    4 years ago
  • Next talk.
    4 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 :-)
    4 years ago
  • 4 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.
    4 years ago
  • Debugging is tough in microservice architecture. Bit we gain independent scaling, independent failures.
    4 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.
    4 years ago
  • Until you have to.
    4 years ago
  • Keep it single threaded, that's convenient for node.
    4 years ago
  • HTTP is for communication with clients, events are for talking between services.
    4 years ago
  • The central conceit of microservices is an idea that goes back to the 70s.
    4 years ago
  • Open VMS is an OS that was about 2 or 3 decades ahead of it's time. #mucon2015
    4 years ago
  • What we are missing in a monolith is independent deployment.
    4 years ago
  • Developers are good at writing monoliths. We know how to write monoliths.
    4 years ago
  • 4 years ago
  • Most successful software is a big ball of mud. Apparently there is a paper you can read on this.
    4 years ago