Microservice The Evolutionary Architecture Software Engineering II Sharif University of Technology MohammadAmin Fazli
Topics An Evolutionary Vision for the Architecture Zoning A Principal Approach Governance Through Code Technical Debt Exception Handling Governance from the Center Building a Team Reading: Building Microservices-Sam Newman-Chapter II Evolutionary Architecture 2
Inaccurate Comparisons We are not real architectures in software engineering Architects and engineers have a rigor and discipline we could only dream of, and their importance in society is well understood We plainly don ’ t what we are doing. The number of times buildings and bridges fall down is much less than the number of times our programs will crash. 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 and 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. In our industry, this view of the architect leads to some terrible practices: many diagrams created with a view of the perfect system, utterly devoid of any understanding as to how hard it will be to implement, or whether or not it will actually work Evolutionary Architecture 3
An Evolutionary Vision for the Architect Our requirements shift more rapidly than they do for people who design and build buildings. The things we create are not fixed points in time: our software will continue to evolve as the way it is used changes. Our architects need to shift their thinking away from creating the perfect end product, and instead focus on helping create a framework in which the right systems can emerge, and continue to grow as we learn more. We are more as town planner than architects Planners ’ roles: Look at a multitude of sources of information Optimize the layout of a city to best suit the needs of the citizens Zonning the city; does not say “ build this specific building here ” Town planners does not worry much about what happens inside a zone, he spends time working on how things move from one zone to other. Evolutionary Architecture 4
An Evolutionary Vision for the Architect We are more as town planner than architects City/Software changes over time; It shifts and evolves as its occupants use it in different ways, or as external forces shape it. The town planner/architect does his best to anticipate these changes, but accepts that trying to exert direct control over all aspects of what happens is futile. City/Software must be habitable for City: Different citizens Software: Users, Developers, Operation people A town planner/Architect needs to know when his plan isn ’ t being followed. As he is less prescriptive, the number of times he needs to get involved to correct direction should be minimal, but if someone decides to build a sewage plant in a residential area, he needs to be able to shut it down. Architects as town planners need to set direction in broad strokes, and only get involved in being highly specific about implementation detail in limited cases Evolutionary Architecture 5
An Evolutionary Vision for the Architect Evolutionary Architecture 6
Zoning What are zones? Service boundaries? Coarse grained groups of services? As architects, we need to worry much less about what happens inside the zone than what happens between the zones How they talk with each other Ensuring that we can properly monitor the overall health of our system Within each service, architect may be OK with the team who owns that zone picking a different technology stack or data store. It may have some drawbacks Hiring people Hard to scale Evolutionary Architecture 7
Zoning Architect may establish some standards on the zones Netflix standard on choosing Cassandra as data storage Integration technology: REST, Java RMI, Protocol buffers (ex. Apache Thrift) Coding standards: Pair programming, QSD best practices, … . A very important best practice: Architect should join teams for a short period as one member of the pair. Ideally, architect should work on normal stories, to really understand what normal work is like. Evolutionary Architecture 8
A Principal Approach Making decisions in system design is all about trade-offs, and microservice architectures give us lots of trade-offs to make. The principal approach Strategic goals Principles Practices Combining principles and practices The Principal Approach to the Great Dagon Pagoda at Rangoon Joseph Moore Evolutionary Architecture 9
Strategic goals The role of the architect is not to define strategic goals Strategic goals should speak to where your company is going, and how it sees itself as best making its customers happy. Expand into Southeast Asia to unlock new markets Let the customer achieve as much as possible using selfservice The key is that this is where your organization is headed, so you need to make sure the technology is aligned to it. This is more a business job Evolutionary Architecture 10 10
Principles Principles are rules you have made in order to align what you are doing to some larger goal, and will sometimes change. Strategic goal: to decrease the time to market for new features Principle: delivery teams have full control over the lifecycle of their software to ship whenever they are ready Strategic goal: moving to aggressively grow its offering in other countries Principle: the entire system must be portable to allow for it to be deployed locally in order to respect sovereignty of data About 10 principles is good. Example: Heroku ’ s 12 Factors are a set of design principles structured around the goal of helping you create applications that work well on the Heroku platform Some of the principles are actually constraint based on behaviors your application needs to exhibit in order to work on Heroku. A constraint is really something that is very hard (or virtually impossible) to change, whereas principles are things we decide to choose. Evolutionary Architecture 11 11
Practices The practices are how we ensure our principles are being carried out. hey are a set of detailed, practical guidance for performing tasks. Often technology specific Low level enough that any developer can understand them Will often change more often than principles Examples: Coding guidelines All log data needs to be captured centrally HTTP/REST is the standard integration style. Evolutionary Architecture 12 12
Practices As with principles, sometimes practices reflect constraints in your organization. If you support only CentOS, this will need to be reflected in your practices. Practices should underpin our principles. Example Principle: delivery teams control the full lifecycle of their systems Example Practice: All services are deployed into isolated AWS accounts Evolutionary Architecture 13 13
Combining Principles and Practices One person ’ s principles are another ’ s practices. Example: You might decide to call the use of HTTP/REST a principle rather than a practice Is mixing principles and practices a good idea? The key point is that there is value in having overarching ideas that guide how the system evolves, and in having enough detail so that people know how to implement those ideas. For a small enough group, perhaps a single team, combining principles and practices might be OK. For larger organizations, where the technology and working practices may differ, you may want a different set of practices in different places, as long as they both map to a common set of principles Evolutionary Architecture 14 14
Example Evolutionary Architecture 15 15
The Required Standard The System needs to be a cohesive system made of many small parts with autonomous lifecycles but all coming together We should not allow too much divergence We need a tradeoff between optimization and autonomy Standardization issues: Monitoring: It is essential that we are able to draw up coherent, cross-service views of our system health. Mechanism: Push & Poll Technology (Graphite for metrics, Nagios for system health) Interfaces: Picking a small number of defined interface technologies helps integrate new consumers. Having one standard is a good number. Two isn ’ t too bad, either. More is bad. Evolutionary Architecture 16 16
The Required Standard Standardization issues: Architectural Safety: We have to ensure that our services shield themselves from unhealthy, down-stream calls. The more services we have that do not properly handle the potential failure of downstream calls, the more fragile our systems will be. This means you will probably want to mandate as a minimum that each downstream service gets its own connection pool, and you may even go as far as to say that each also uses a circuit breaker. Response codes must be standard: For HTTP, one service decides to send back 2XX codes for errors, or confuses 4XX codes with 5XX codes, then these safety measures can fall apart. Evolutionary Architecture 17 17
Recommend
More recommend
