# Microservice Notes
## A Combined Model
- We want some quick wins to make early progress, to build a sense of momentum, and to get early feedback on the efficacy of our approach.

- both forms of prioritization make sense, but we need a mechanism for visualizing both together and making appropriate trade-offs

- For each candidate service to be extracted, you place it along the two axes displayed. The x-axis represents the value that you think the decomposition will bring. Along the y-axis, you order things based on their difficulty.
- like every good quadrant model, it’s the stuff in the top right.

## Reorganizing Teams

- Aligning architecture and organization can be key to getting the most out of a microservice architecture.

## Shifting Structures

Concept:
- **A vertical slice** is a top to bottom, fully implemented and tested piece of functionality that provides some form of business value to an end user. Most important, it should be possible to easily deploy a vertical slice into production upon request
- https://www.slideshare.net/skydiver34275/vertical-slicing-v2
- https://medium.com/@jacobcunningham/out-with-the-onion-in-with-vertical-slices-c3edfdafe118

## It’s Not One Size Fits All
`How your decision about whether to use micro‐ services should be rooted in the challenges you are facing, and the changes you want to bring about`

**Making changes in your organizational structure is just as important**

- Understanding if and how your organization needs to change needs to be based on your context, your working culture, and your people
- Just copying other people’s organizational design can be especially dangerous.

**Spotify Model is an example:**

https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

- The same needs to apply to you:
- Don’t assume that what worked for someone else will work in your context.
- Copy that flexible, questioning attitude in how you do things, and try new things, but make sure the changes you apply are rooted in an understanding of your company, its needs, its people, and its culture.

- Not based on something like Spotify, copy flexible, questioning attitude in how you do things, and try new things, but make sure the changes you apply are rooted in an understanding of your company, its needs, its people, and its culture.

## DevOps doesn't mean NoOps
- with some people assuming that it means that developers do all the operations, and that operations people are not needed.
- **This is far from the case**
- DevOps is a cultural movement based on the concept of breaking down barriers between development and operations.
- You want to promote common alignment and understanding across the people involved in delivering your software, no matter what their specific responsibilities are.

## Making a Change
- Begin with explicitly listing all the activities and responsibilities that are involved in delivering software within that company
- Next, map these activities to your existing organizational structure.
- brainstorm as a group all the activities that go into shipping software in your company.


- Having this understanding of the current “as-is” state is very important, as it can help give everyone a shared understanding of all the work involved

`If you find your delivery teams are already deploying software themselves for test and user testing purposes, then the step to production deployments may not be that large`

- Example: we see that we’ve decided to merge front‐ end and backend team responsibilities

- The delivery team to ultimately handle all support for their software, and so we want to start the teams getting happier with the work involved.
- Having them owning their own test deployments is a good first step.
- Decided they’ll handle all incidents during the working day, giving them a chance to come up to speed with that process in a safe environment, where the existing operations team is on hand to coach them.

**The big picture views can really help when starting out with the changes you want to bring**
- need to spend time with the people on the ground to work out whether these changes are feasible.
- By dividing things among specific responsibilities, you can also take an incremental approach to this shift.
- focusing first on eliminating the need for the operations teams to provision test environments is the right first step.
## Changing Skills

Example: The Guardian newspaper rebuild its online presence

- At the start of the project, our combined teams came up with a list of core skills that were important for The Guardian developers to work on.
- Each developer then assessed themselves against these criteria, ranking themselves from 1 (“This means nothing to me!”) to 5 (“I could write a book about this”).

- Each developer’s score was private; this was shared only with the person who was mentoring them
- The goal was not that each developer should get each skill to 5; it was more that they themselves should set targets to reach.

`As a coach, it was my job to ensure that if one of the developers I was coaching wanted to improve their Oracle skills, I would make sure they had the chance to do that. This could involve making sure they worked on stories that made use of that technology, recommending videos for them to watch, consider attending a training course or conference, etc.`

- You can use this process to build up a visual representation of the areas where an individual may want to focus their time and effor
- *Just as important is highlighting those areas you are happy with—in this example, I feel that my Go coding is not something I need to focus on right now.*

**Keeping these sorts of self-assessments private is very importan**
- The point isn’t for someone to rate themselves against someone else; it’s for people to help guide their own development.

**In another context**
- Although each score is private, you can still use this to build up a picture of the team as a whole.
- Take the anonymized self-assessment ratings and develop a skill map for the overall team. This can help highlight gaps that may need addressing at a more sys‐ temic level.


- This might highlight the need for some group learning, and perhaps justify a bigger investment such as run‐ ning an internal training course. Sharing this overall picture with your team can also help individuals understand how they can be part of helping the team as a whole find the balance it needs.

- Changing the skill set of the existing team members isn’t the only way forward, of course
- What we’re often aiming for is a delivery team that as a whole takes on more responsibilities.
- Rather than helping the developers learn more about Kafka, you could hire a Kafka expert to join your team -> This could solve the short-term problem, and you then have an in-team expert who can help their colleagues learn more in this area too

## How Will You Know if the Transition Is Working?

`Do you know if it is working? Have you made a mistake?`

- Based on the outcomes you are hoping to achieve.
- take into account qualitative feedback from the people at the coalface.
- These measures, quantitative and qualitative, should inform an ongoing review process. You need to establish checkpoints that will allow your team time to reflect on whether you’re heading in the right direction.
- The question to ask yourself during these checkpoints
- Is this working?
- Should we try something else instead?

Some way as below:
### Having Regular Checkpoints
- Build into your delivery process some time for pause and reflection in order to analyze the available information and determine whether a change of course is required.
- For small teams, this could be informal, or perhaps folded into regular retrospective exercises.
- For larger programs of work, they may need to be planned in as explicit activities on a regular cadence.

**No matter how frequently you run these exercises, and no matter how formal**
1. Restate what you are expecting the transition to microservices to achieve. If the business has changed direction such that the direction you’re going in no longer makes sense, then stop!
2. Review any quantitative measures you have in place to see whether you’re making progress.
3. Ask for qualitative feedback—do people think things are still working out?
4. Decide what, if anything, you’re going to change going forward.
### Quantitative Measures

### Avoiding the Sunk Cost Fallacy

### Being Open to New Approaches

## Summary