Pietro Menna Home page

Never install a database again

Yesterday I went to FISL to watch some of the talks. I learned a lot in just a few hours and got impressed how networking and events such as conferences can make participants to learn such amount of content in just few time.

Some of the talks I went to listen were about Docker and others about UX and MongoDB.

Docker

The speaker of the docker talk I went to see, said an interesting phrase: “Never install a database again”. His point was that Docker allowed us to have the service we need without having to install in a local environment again.

Some years ago, when we wanted to to have development environments which we could share with someone else, we created a Vagrant image. Which was a virtualized, full installation of a operating system, the databases required, and the libraries required.

Whenever we needed to upgrade a component in that image (lets say a new version of ruby), you needed to create a new image and distribute it again. We can say that the image would be large.

Docker allows to share a container (which happens to be a minimal image of a operating system which only provides a single service). By service we can assume a “Database”, or a “Web Server”, or any other type of application communicates via network socket.

Docker composer

What most impressed me was that in a 1 hour time, it was shown how to generate 4 development environments by using Docker Compose.

With Docker Compose it is possible to define the services which interact with you application. It is basically a way to define multi-container environment for your application in which each container contains a part of your application.

In order to define the multi-container environment, the developer has to set up a docker-compose.yml which described the application. More information here.

Not installing MongoDB as example (but having available)

Cool, but I just want to benefit to install easily a Database, not using composer or anything like that yet! Let`s try MongoDB.

In order to achieve this, we can follow the steps:

  1. Install Docker, in my case, I installed Docker for Mac. There is also the Windows version, and of course the linuxes versions which depends on your linux flavor you use.

  2. All next steps are on the terminals. Ensure your deamon is running.

      $ docker version
      Client:
       Version:      1.12.0-rc2
       API version:  1.24
       Go version:   go1.6.2
       Git commit:   906eacd
       Built:        Fri Jun 17 20:35:33 2016
       OS/Arch:      darwin/amd64
       Experimental: true
      Cannot connect to the Docker daemon. Is the docker daemon running on this host?
    

If you get that, you need to ensure that Docker deamon is running. In that case you will get something similar to:

    $ docker version
    Client:
     Version:      1.12.0-rc2
     API version:  1.24
     Go version:   go1.6.2
     Git commit:   906eacd
     Built:        Fri Jun 17 20:35:33 2016
     OS/Arch:      darwin/amd64
     Experimental: true
    
    Server:
     Version:      1.12.0-rc2
     API version:  1.24
     Go version:   go1.6.2
     Git commit:   a7119de
     Built:        Fri Jun 17 22:09:20 2016
     OS/Arch:      linux/amd64
     Experimental: true`
  1. Get the image you are looking for. Also if you have a chance, browse for it on Docker Hub. For mongo it is here. For getting the image, use docker pull

     $ docker pull mongo
     Using default tag: latest
     latest: Pulling from library/mongo
     8ceedfe606fc: Already exists
     de56a622d4ac: Already exists
     6f6965220a2d: Already exists
     290580b9cb91: Already exists
     74518025c1d4: Already exists
     7caf7e3d8fb7: Pull complete
     dcfe9afaf914: Pull complete
     b3c5b8f22de4: Pull complete
     b66f9b8214cf: Pull complete
     Digest:         sha256:fc89af57055910959cd94c3f852150fc0dafc95e2b081            b57d109711dbcf0d506
     Status: Downloaded newer image for mongo:latest
    
  2. You are ready now, just run the image my forwarding the port of the service you need:

     $ docker run -d -p 27017:27017 -p 28017:28017 mongo
        
     curl localhost:27017
     It looks like you are trying to access MongoDB over HTTP on the native driver port.
    
  3. It worked!

Now I have a working mongodb service running on my machine and I am ready to learn Mongo!

Conclusion

It is possible to avoid the hassle of installing software which is not always necesary on your computer by using Docker. Docker also provides mechanisms for developers to create virtual environments which are replicable on any machine which runs Dockers thanks to the container technology.

The problem of eBooks Business Model

The expectation of readers of eBooks is different to the readers of paper books. They are completely different technologies and its users have different expectations. The expectation also depends on the type of content of the book/eBook.

Currently there are some publishers and authors who struggle to see the difference, they keep publishing eBooks as if they were only books. In some cases, example for technical content eBooks (example: eBooks about a programming language), this should be unacceptable.

Different expectations for different models

Novels

Reading novels on a paper book feels a lot better than reading on a eBook. You feel the paper, you can carry anywhere, and also the reader is usually pride and wants to show what novel is currently reading.

Novels also do not get updated, it is rare (or inexistent) the case in which a novel has a new version. Usually only a few words gets changed from one print to another, the content is the same.

When a reader buys a novel as eBook, its expectation is usually to read on a Kindle device, or his iPad, or any other digital media. His expectation is that the content is readable on his device, and that the content is the same as the printed book.

Technical books

When a reader buys a technical book, because he wants to learn a new technology, he expects that the book is accurate and the examples contained on it work. It is understandable, that a typo may have gotten through and go to an errata on a web site.

When a publisher/author charges extra for the digital version, the expectation is the same as if it was a novel book, plus that the eBook will be updated with the new prints. If the reader downloads the latest version, it should be reading a version in which the errata is already corrected.

The technology business model of books/eBooks

Technology is always evolving, and changes to software, programming languages are inevitable. Some changes are also not backwards compatible. As an author, it is great opportunity to get a technology from the begin and publish a book about it.

If the initial book is successful, and lot of changes occurred to the software/programming language, it is an opportunity again to make money! You can release a new version of the book with updates! Specially if you wrote a very good previous version, lots of people will buy the new version.

For a reader, it may be interesting to buy the new version if many things changed, but otherwise it will just stick with the old one.

eBooks as opportunity

For authors, an eBook should be an opportunity to keep the readers updated with any small change that may come. This is a way to keep them reading the content which was initially sold in a more accurate way.

When a book contains examples which are to be run on a computer, they must be working! If a small change on the language software breaks an eBook, the author has an opportunity to make a small correction and release it in the latest version of the eBook. This practice is better than keeping an errata or a “companion”.

Just buy the next edition

This is what you would usually hear as a reader, but in days that subscription model is what we hear, and that re-generating an eBook should take the same amount of time that writing an errata, you should have the most accurate content available.

We should actually pay for new content. For example, a new version is released which requires major rework for the author, we should pay for it. Maybe not the full price, but it is even understandable.

My bad experience

When you buy an eBook about Cocoa Programming for Mac OS X, you expect the examples to work. You do not expect to read the eBook, watch the examples not to compile, and read a companion.

The people from Big Nerd Ranch actually have the best books for Cocoa and iOS, and they are very professional to release the companion guide.

Unfortunately, my expectation nowadays is not a companion, but a new eBook version which contain the changes from the companion.

I bought the previous edition of this book , and decided to buy the current version because of the change from Objectice C to Swift. I wouldn’t have bought if I knew I would have to read a book in which the examples do not compile!

It does not compile not because of the authors are careless, but I think it is related to be published by informit. I have not yet seen an eBook from this publisher to be updated. I suspect this bad practice comes from the publisher which has an outdated business model.

Don’t get me wrong, informit publishes great books from awesome authors, but this practice of not updating is not correct!

My good experiences

The expectations I have mentioned in this post comes from the books and eBooks I buy from the Pragmatic Programmers site.

Their good practices are:

  • Update eBooks instead of errata.
  • Small updates even on code examples, creates a new version of the eBook, and this is usually free.
  • New versions of eBooks, usually come as an upgrade of the previous version, sometimes with discounts.
  • The reader receives updates about the eBooks he owns.

There are other authors and publishers which also follow these practices. This is what I expect as a technology guy who reads technical stuff.

Summary

The content of a book determines the expectation of the eBook version. Some publishers still works in a Business model which is no longer the ideal for the reader point of view for technical eBooks.

Maybe as readers we should demand more from the publishers and cheer the publishers and authors who play nice.

My understanding of Microservices

No matter where you look into the Internet, of the trends you always read the same buzzwords: Big Data, DevOps and Microservices. I plan to explain what I understood the talks I watched here, here and some others, but I am in no way an expert on the subject.

Monoliths and Microservices

Before begin, lets imagine that we are a shop with three “components”: Finance & Accounting, Distribution and the Store. A component would be a working group of the organization represented in the system.

Usually applications are built as monoliths. In our example, it means, that in the same system, we have all the components together. They share the same source code, technology stack and datastore. It also runs everything on the same server. So imagine that we have to reset the system because of a problem with the Distribution; the “Finance & Accounting” will also be down during the system reset.

Oh, I forgot, there is the IT group which is in charged of all the applications!

Lets imagine now the same shop, but that runs as microservices. We have the same “components” with the only exception of the IT group. Instead, each of the groups has like 3 - 4 people working on only on their specific application. For example, the “store” group, only works on the “store”. The people from the Store may decide to use NodeJS and MongoDB while the Finance & accounting people would prefer Ruby on Rails and Postgres.

Each group decides its own technology stack, and if one of the groups needs to reset their system, not all groups are offline because of it.

It is time to add another buzzword: The Conway`s law, which states:

“…Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations…”

Back to our example, everyone agrees that in the shop all the “components” needs to talk to each other in real life. They all depend on each other so the “Store” is successful.

In microservices world, every user request is a sequence of requests

Let’s say I am an external user, I want to buy something on the “store”, when I buy something on the store, I do not know and I do not care if they are all in one system. I just expect my goods to be delivered and to pay for it.

When I buy something, behind the scenes, the Store component would communicate with the distribution component in charged with the shipping. Also after getting billed, probably the F&A component would get notified.

As you can see in this example, since they are all different systems (maybe even computers), as a user I do not know that. Also, you can see that the system is distributed.

Let’s talk in “Developer’s terms”

  • RESTful Architecture: the communication should occur in RESTful way. In many places you can read this as the Smart endpoints, dumb pipes.
  • Distributed Data Governance: each of the components decides its technology stack, also its data store. This is because you can choose depending on the requirements of each component. Remember, not every problem is a nail and not every solution is a hammer.
  • Single Responsibility: The store component, is only responsible for being a good store for customer`s to buy. Nothing else! One Component: one responsibility.
  • You share nothing: A developer from the Store does not have access to the datastore or even code from the F&A component. All the communication should occur via the common interface.
  • Infrastructure automations: Since you own your stack, you probably need to know how to generate your own system and how to run it. Developers probably woud need to have code as infrastructure to take care of its own system.

Some of the origins

It is said that Microservices is a consequence of Conway’s Law and DevOps. It is also said many ideas come from Amazon.

In particular, Amazon is known for the two pizza size team (a team should have no more people than the amount of people who can be fed with 2 American pizzas). This means, the team should have a size of less than 10-12 people, and most important have the accountability and autonomyto execute its task.

Microservices teams also follow the “Products, not projects” mentality. We can say “Product” is “Component”. Each team should take care of its Product even the operations side: this is also known as the “You build it, you run it!”.

Implications & Conclusion

For developers, everything should be thought from day zero to be externalizable to be able to work on a microservices world.

Also, it has some drawback, since it is distributed system, the problems which may occur are more difficult!