"Building microservices" by Sam Newman ( O'Reilly)

User avatar
Сабина
Уже с Приветом
Posts: 19045
Joined: 11 Jan 2012 09:25
Location: CA

"Building microservices" by Sam Newman ( O'Reilly)

Post by Сабина »

Книжка нравится :)

Вот для затравки первая часть первой главы. Посколько ее дают скачать за просто так надеюсь можно и тут привести весь текст
As we have seen so far, Microservices give us an a lot of choice, and also a lot of things to trade off against each other. How do we go about making these decisions? With the faster pace of change, and the more fluid environment that these architectures allow, the responsibilities of the role of the architect also has to change. In this chapter I’ll take a fairly opinionated view of what the role of an architect is, and hopefully launch one final assault on the ivory tower. Inaccurate Comparisons “You keep using that word. I do not think it means what you think it means.” — Inigo Montoya from The Princess Bride Architects have an important job. They are in charge of making sure we have a joined up technical vision, one that should help us deliver the system our customers need. In some places, they may only have to work with one team, in which case the role of the architect and technical lead is often the same. In others, they may be defining the vision for an entire programme of work, working with multiple teams across the world, or perhaps even an entire organisation. At whatever level they operate at, the role is a tricky one to pin down, and despite it often being the obvious career progression for developers in enterprise organisations it is also a role that gets more criticism than virtually any other. Architects have more ability to have a direct impact on the quality of the systems built, for the working conditions of their colleagues and for their organisations ability to respond to change than any other, and yet we so frequently seem to get this role wrong. Why is that? Our industry is a young one. This is something we seem to forget, and yet we have been only creating programs that run on things that we would recognise as computers for around seventy years. As such, we are constantly looking to other professions in an attempt to explain what we do. We aren’t medical doctors or engineers, but nor are we plumbers or electricians. Instead we fall into some middle ground which makes it hard for society to understand us, or for us to understand where we fit. So we borrow from other professions. We call ourselves Software “Engineers”, or “Architects”. But we aren’t, are we? Architects and Engineers have a rigour and discipline we could only dream of, and their importance in society is well understood. I remember talking to a friend of mine, the day before he became a qualified architect. “Tomorrow” he said, “If I give you advice down the pub about how to build something and it’s wrong, I get held to account. I could get sued as in the eyes of the law I am now a qualified architect and I should be held responsible if I get it wrong”. The importance of these jobs to society means that there are required qualifications people have to pass. In the UK for example, a minimum of seven years study is required before you can be called an architect. But these jobs are also based on a body of knowledge going back thousands of years. And us? Not quite. Which is also why I view most forms of IT certification as worthless, as we know so little about what good looks like. Part of us wants recognition, so we borrow names from other professions which already have the recognition that as an industry we crave. But this can be doubly harmful. Firstly, it implies we know what we are doing, when we plainly don’t. I wouldn’t say that buildings and bridges never fall down, but they fall down much less than the number of times our programs will crash, making comparisons with engineers quite unfair. Secondly the analogies break down very quickly when given even a cursory glance. To turn things around, if bridge building was like programming, half way through we’d find out that the far bank was now 50 meters further out, was actually mud rather than granite, and that rather than building a foot bridge we were instead building a road bridge. Our software isn’t constrained by the same physical rules that real architects or engineers have to deal with, and what we create is designed to flex and adapt an evolve with user requirements. Perhaps the term architect has done the most harm. The idea of someone who draws up detailed plans for others to interpret, and expects this to be carried out. The balance of part artist, part engineer, overseeing the creation of what is normally a singular vision. With all other viewpoints being subservient, except for the occasional objection from the structural engineer regarding the laws of physics. In our industry, this view of the architect leads to some terrible practices. Diagram after diagram, page after page of documentation created with a view to inform the creation of the perfect system, without taking into account the fundamentally unknowable future. Utterly devoid of any understanding as to how hard it will be to implement, or whether or not it will actually work, let alone having any ability to change as we learn more. When we compare ourselves to engineers or architects, we are in danger of doing everyone a disservice. Unfortunately we are stuck with the word architect for now. So the best we can do is to try and redefine what it means in our context.
https://www.youtube.com/watch?v=wOwblaKmyVw
User avatar
Сабина
Уже с Приветом
Posts: 19045
Joined: 11 Jan 2012 09:25
Location: CA

Re: "Building microservices" by Sam Newman ( O'Reilly)

Post by Сабина »

Книга не перестает радовать :). Если кому придется с микросервисами работать - это наверное bible на сегодняшний день.
Читаю как story of my life :)

Я в начале проекта чуть не подралась с одним товарищем, который уверял что backend services надо дизайнить "от базы".
Автор книги очень метко написал насчет этого
Beware Too Much Convenience

As REST has become more popular, so too have the frameworks that help us create RESTFul web services. However, some of these tools trade off too much in terms of short-term gain for long-term pain; in trying to get you going fast, they can encourage some bad behaviors. For example, some frameworks actually make it very easy to simply take database representations of objects, deserialize them into in-process objects, and then directly expose these externally. I remember at a conference seeing this demonstrated using Spring Boot and cited as a major advantage. The inherent coupling that this setup promotes will in most cases cause far more pain than the effort required to properly decouple these concepts. There is a more general problem at play here. How we decide to store our data, and how we expose it to our consumers, can easily dominate our thinking. One pattern I saw used effectively by one of our teams was to delay the implementation of proper persistence for the microservice, until the interface had stabilized enough. For an interim period, entities were just persisted in a file on local disk, which is obviously not a suitable long-term solution. This ensured that how the consumers wanted to use the service drove the design and implementation decisions. The rationale given, which was borne out in the results, was that it is too easy for the way we store domain entities in a backing store to overtly influence the models we send over the wire to collaborators. One of the downsides with this approach is that we are deferring the work required to wire up our data store. I think for new service boundaries, however, this is an acceptable trade-off.
https://www.youtube.com/watch?v=wOwblaKmyVw
helloalleo
Posts: 1
Joined: 09 Jun 2017 10:54

Re: "Building microservices" by Sam Newman ( O'Reilly)

Post by helloalleo »

Здравствуйте, какие книги Вы посоветуете на туже тему, только с примерами. Желательно на Spring.
Pantigalt
Уже с Приветом
Posts: 803
Joined: 24 Jan 2007 07:32
Location: Сергели->Новосибирск->SFBA->Новосибирск->Москва->NY->SFBA

Re: "Building microservices" by Sam Newman ( O'Reilly)

Post by Pantigalt »

It is a good book for start.
Спи быстрее, твоя подушка нужна другому. Copyright Зощенко

Return to “Работа и Карьера в IT”