بخش اول اولین کارگاه معماری مایکروسرویس ها
معماری مایکروسرویس به عنوان یکی از جدیدترین روش های معماری سیستم های نرم افزاری در چند سال گذشته بیشترین توجهات را به سمت خود داشت. اولین کارگاه عمومی اختصاصی معماری مایکروسرویس ها در تاریخ 1396/11/04 و 1396/11/11 به مدت هشت ساعت برگزار شد. که در این کارگاه ضمن معرفی و نگاهی به دنیایی مایکروسرویس ها؛ به جنبه های مختلف این سبک معماری پرداخته شد.
پرزنت فعلی بخش اول از این کارگاه می باشد
1. Microservices:
Martin Fowler:
"Microservices" - yet another new term on the crowded streets of software architecture.
https://martinfowler.com/articles/microservices.html
Masoud Bahrami
http://Refactor.Ir
Agile Developer
مایکروسرویسها
24. In 2009, John Allspaw and Paul Hammond
from Flickr at O’Reilly Velocity conference
SoundCloud Netflix
25. Agile Software Architecture
Agile Software Architecture is built using a collection of small, loosely coupled
components/services that collaborate together to satisfy an end-goal.
Provides agility.
Small loosely coupled components/services van be built, modified and tested in
isolation or even ripped out and replaced depending on how requirements change.
This style of architecture also lends itself well to a very flexible and adaptable
deployment model, since new components/services can be added and scaled if needed.
35. برای لوئیز جیمز که های ویژگی
برشمرد های مایکرسرویس
•Small with a Single Responsibility
•Containerless and installed as well behaved Unix services
•Located in different VCS roots
•Provisioned automatically
•Status aware and auto-scaling
36.
37.
38. • James Lewis:
•Capabilitiesطریق از تعامل با هاUniform Interfacesبا
دارند تعامل یکدیگر
•هرچندJames LewisازRESTfulویژگی ولی نکرده صحبتی
برای را زیر هایUniform Interfacesشمرد بر:
•HTTP(Be of the web, not behind the web)
•HATOS
•Standard Media Types
Capabilitiesصورت چه به هاProductرا
دهند می تشکیل
41. تیک دادن انجام خوب روی بر مرکز
چیز
•هرiterationمقداریcodeبهcode baseمی افزوده اولیه
شود
Robbert C.Martin:
Gather together those things that change for the same reason, and separate those things that change
for different things.
یعنی کوچک؛ سرویس
اندازه؟؟؟ چه
In each of RPC technologies, the basic idea was to make remote calls transparent to developers. The promise was that if developers didn’t have to care whether the procedure calls or methods they were invoking were local or remote, then they could build larger machine-crossing systems that could avoid the processing and memory scalability issues that affected systems of the time. (Remember that the most common processors at this time were 16-bit processors with a 64K address space!)
-----------
The Façade pattern was about encapsulating the unstructured interfaces of a large system within a single, more structured interface to reduce “chattiness.”
----------
The Session Façade approach, applied Facade pattern to distributed systems by identifying the key, large-grained interfaces of an entire subsystem and exposing only those for distribution.
----------------
We implemented our first Session Façades with Enterprise JavaBeans (EJBs), which, while fine if you were only working in Java, were complicated, difficult to debug, and not interoperable with other languages or even other vendor products. That lack of interoperability led directly to the next effort of the early to mid 2000s: what would become known as Service Oriented Architecture (SOA). SOA didn’t start out with such grandiose terminology, though. It originally began as a “do the simplest thing that could possibly work” effort called Simple Object Access Protocol (SOAP), originally released by Microsoft in 1999.
---------------
At its heart, SOAP was nothing more than a way of invoking object methods over HTTP.
In early 2001, a group of software professionals published the Agile Manifesto as a statement of values on how to improve software development. Although the principles stated were not new -- they were a consolidation of ideas from extreme programming, scrum, lean, and more -- the unified voice caught the industry’s attention. Just as microservice architecture is frequently defined in contrast to monolithic architecture, the manifesto differentiates agile software development from “documentation-driven, heavyweight software development processes.” The agile approach sought to remove the overhead and risk of large-scale software development by using smaller work increments, frequent iterations, and prototyping as a means of collaboration with users. The adoption of agile methods in the industry grew consistently following the publication of the manifesto.
In early 2001, a group of software professionals published the Agile Manifesto as a statement of values on how to improve software development. Although the principles stated were not new -- they were a consolidation of ideas from extreme programming, scrum, lean, and more -- the unified voice caught the industry’s attention. Just as microservice architecture is frequently defined in contrast to monolithic architecture, the manifesto differentiates agile software development from “documentation-driven, heavyweight software development processes.” The agile approach sought to remove the overhead and risk of large-scale software development by using smaller work increments, frequent iterations, and prototyping as a means of collaboration with users. The adoption of agile methods in the industry grew consistently following the publication of the manifesto.
Still, there were bottlenecks. Agile’s primary scope was on the development of software, while CD extended that scope to include production deployment, an operations task. In most organizations, development and operations were consciously divided in both reporting and mission. In 2009, John Allspaw and Paul Hammond from Flickr gave an influential talk at the O’Reilly Velocity conference detailing how they had bridged this gap. From experiences like theirs, the devops movement arose to address this cultural divide.
I'm back in The Netherlands next week to deliver the opening keynote at the Agile Software Architecture Symposium, where I'll be speaking about agility and the essence of software architecture. But what does "agile software architecture" actually mean?
-----------------------------------------------------------------
In my experience, people tend to use the word "agile" to refer to a couple of things. The first is when talking about agile approaches to software development; moving fast, embracing change, releasing often, getting feedback and so on. The second use of the word relates to the agile mindset and how people work together in agile environments. This is usually about team dynamics, systems thinking, psychology and other things you might associate with creating high performing teams.
----------------------------------------
Leaving the fluffy stuff aside, for me, labelling a software architecture as being "agile" means that it can react to change within its environment, adapting to the ever changing requirements that people throw at it. This isn't necessarily the same as the software architecture that an agile team will create. Delivering software in an agile way doesn't guarantee that the resulting software architecture *is* agile. In fact, in my experience, the opposite typically happens because teams are more focussed on delivering functionality rather than looking after their architecture.
------------------------------------------------------
If we look at the characteristics of an agile software architecture, we tend to think of something that is built using a collection of small, loosely coupled components/services that collaborate together to satisfy an end-goal. This style of architecture provides agility in a number of ways. Small, loosely coupled components/services can be built, modified and tested in isolation, or even ripped out and replaced depending on how requirements change. This style of architecture also lends itself well to a very flexible and adaptable deployment model, since new components/services can be added and scaled if needed. However, nothing in life is ever free. Building a software system like this takes time, effort and discipline. Many people don't need this level of adaptability either, which is why you see so many teams building software systems that are much more monolithic in nature, where everything is bundled together and deployed as a single unit. Although simpler to build, this style of architecture usually takes more effort to adapt in the face of changing requirements because functionality is often interwoven across the codebase. With pragmatism in mind, you can always opt to build a software system that consists of a number of small components yet is still deployed as a single unit. You need to understand the trade-offs and make your choices accordingly.
However you build your software system, creating a well structured architecture isn't something that happens all by itself. You need to put time, effort and discipline into it. In order to do this, everybody on the team needs to understand software architecture and contribute to its success. How you do this is what my talk is all about...
The term "microservice" was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring.
In May 2012, the same group decided on "microservices" as the most appropriate name.
James presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow in Microservices - Java, the Unix Way as did Fred George about the same time.
Adrian Cockcroft at Netflix, describing this approach as "fine grained SOA" was pioneering the style at web scale as were many of the others mentioned in this article - Joe Walnes, Dan North, Evan Botcher and Graham Tackley.
The term "microservice" was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring.
In May 2012, the same group decided on "microservices" as the most appropriate name.
James presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow in Microservices - Java, the Unix Way as did Fred George about the same time.
Adrian Cockcroft at Netflix, describing this approach as "fine grained SOA" was pioneering the style at web scale as were many of the others mentioned in this article - Joe Walnes, Dan North, Evan Botcher and Graham Tackley.
To start explaining the microservice style it's useful to compare it to the monolithic style: a monolithic application built as a single unit. Enterprise Applications are often built in three main parts: a client-side user interface (consisting of HTML pages and javascript running in a browser on the user's machine) a database (consisting of many tables inserted into a common, and usually relational, database management system), and a server-side application. The server-side application will handle HTTP requests, execute domain logic, retrieve and update data from the database, and select and populate HTML views to be sent to the browser. This server-side application is a monolith - a single logical executable[2]. Any changes to the system involve building and deploying a new version of the server-side application.
Such a monolithic server is a natural way to approach building such a system. All your logic for handling a request runs in a single process, allowing you to use the basic features of your language to divide up the application into classes, functions, and namespaces. With some care, you can run and test the application on a developer's laptop, and use a deployment pipeline to ensure that changes are properly tested and deployed into production. You can horizontally scale the monolith by running many instances behind a load-balancer.
-----------------------------------------------------------------------------------------
Monolithic applications can be successful, but increasingly people are feeling frustrations with them - especially as more applications are being deployed to the cloud . Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it's often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires scaling of the entire application rather than parts of it that require greater resource.
-----------------------------------------------------------------
These frustrations have led to the microservice architectural style: building applications as suites of services. As well as the fact that services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams .
We do not claim that the microservice style is novel or innovative, its roots go back at least to the design principles of Unix. But we do think that not enough people consider a microservice architecture and that many software developments would be better off if they used it.
-------------------------------------------------------
Successful applications have a habit of growing over time and eventually becoming huge. During each sprint, your development team implements a few more stories, which, of course, means adding many lines of code. After a few years, your small, simple application will have grown into a monstrous monolith.
-----------------------------------------------------------------------------
Once your application has become a large, complex monolith, your development organization is probably in a world of pain. Any attempts at agile development and delivery will flounder. One major problem is that the application is overwhelmingly complex. It’s simply too large for any single developer to fully understand. As a result, fixing bugs and implementing new features correctly becomes difficult and time consuming. What’s more, this tends to be a downwards spiral. If the codebase is difficult to understand, then changes won’t be made correctly. You will end up with a monstrous, incomprehensible big ball of mud.
--------------------------------------------------------------------------------The sheer size of the application will also slow down development. The larger the application, the longer the start‑up time is. For example, in a recent survey some developers reported start‑up times as long as 12 minutes. I’ve also heard anecdotes of applications taking as long as 40 minutes to start up. If developers regularly have to restart the application server, then a large part of their day will be spent waiting around and their productivity will suffer.
---------------------------------------------------------------------------------
Another problem with a large, complex monolithic application is that it is an obstacle to continuous deployment. Today, the state of the art for SaaS applications is to push changes into production many times a day. This is extremely difficult to do with a complex monolith since you must redeploy the entire application in order to update any one part of it. The lengthy start‑up times that I mentioned earlier won’t help either. Also, since the impact of a change is usually not very well understood, it is likely that you have to do extensive manual testing. Consequently, continuous deployment is next to impossible to do.
-----------------------------------------------------------------------------------
Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements. For example, one module might implement CPU‑intensive image processing logic and would ideally be deployed in Amazon EC2 Compute Optimized instances. Another module might be an in‑memory database and best suited for EC2 Memory‑optimized instances. However, because these modules are deployed together you have to compromise on the choice of hardware.
----------------------------------------------------------------------------------
Another problem with monolithic applications is reliability. Because all modules are running within the same process, a bug in any module, such as a memory leak, can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug will impact the availability of the entire application.
-------------------------------------------------------------------------------------
Last but not least, monolithic applications make it extremely difficult to adopt new frameworks and languages. For example, let’s imagine that you have 2 million lines of code written using the XYZ framework. It would be extremely expensive (in both time and cost) to rewrite the entire application to use the newer ABC framework, even if that framework was considerably better. As a result, there is a huge barrier to adopting new technologies. You are stuck with whatever technology choices you made at the start of the project.
----------------------------------------------------------------------------------------
To summarize: you have a successful business‑critical application that has grown into a monstrous monolith that very few, if any, developers understand. It is written using obsolete, unproductive technology that makes hiring talented developers difficult. The application is difficult to scale and is unreliable. As a result, agile development and delivery of applications is impossible.
The Microservices Architecture pattern corresponds to the Y‑axis scaling of the Scale Cube, which is a 3D model of scalability from the excellent book The Art of Scalability.
The other two scaling axes are X‑axis scaling, which consists of running multiple identical copies of the application behind a load balancer,
and Z‑axis scaling (or data partitioning), where an attribute of the request (for example, the primary key of a row or identity of a customer) is used to route the request to a particular server.
--------------------------------------------------------------------------------------
Applications typically use the three types of scaling together.
Y‑axis scaling decomposes the application into microservices as shown above in the first figure in this section.
At runtime, X‑axis scaling runs multiple instances of each service behind a load balancer for throughput and availability. Some applications might also use Z‑axis scaling to partition the services.