Pietro Menna Home page

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


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.


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!

Patterns and Integrations

I admit that I am upset that I have to consume an API from a front-end application that reads like methods from something like Java methods. Something like whatever-domain.com/getBusinessAreas.

I hear arguments like no one will consume the link directly, or access this address directly. I am still not convinced it is a good practice.

Patterns, patterns, patterns…

Why do we have Patterns in the Software Industry? to communicate with other developers.

Just like design patterns, there are other types of patterns. The king of Pattern that was violated by the API mentioned before is called an Integration Pattern.

There are a lot of Integration Patterns, just to name some: RMI, SOAP, REST, Message Channels, Pipes, and many others. The ones I am interested here are SOAP and REST.

Choosing between SOAP and REST


SOAP exposes a service, by using a Service Descriptor (right, the WSDL file). All communication is via this service, and it uses an XML “Envelope”.

SOAP in the web came in disuse. I will not say it is dead, a lot of services still use it. Eg: Jira.

I still believe it might be useful in some scenarios. But I am quite sure it not designed for UI-centric consumptions such as browser consumption. So, if a front-end in HTML5 will consume, do not go for SOAP.


It is an Architecture Style. Every RESTful service must respect certain constraints: Client-Server, Stateless, Cacheable, Layered System and Uniform Interface.

A simple example: putting the previous service to REST.

The example from the beginning of this post, could have easily have been named as: GET /BusinessAreas. It would retrieve the list of “Business Areas” that exist in the system.

We could have retrieved the details of one specific, like BusinessArea “1” simply by GET /BusinessAreas/1.

To create a new “Business Area”, we could use POST /BusinessAreas/. In the body of the POST we send the details required to create one.

To update the details for a given business area, we could use PUT /BusinessAreas/1

At last, in order to delete one Business Area, we could use DELETE /BusinessAreas/1. The example would have updated Business Area 1.


The REST approach allowed to remove the ugly camelCase Java like. But actually, the architectural style significantly improves the readability of the service. Imagine you have more entities, they would all follow the same pattern for access.

Does it look simpler? To me at least, yes. It looks a lot better thanks to uniform access pattern gained by following a simple standard.