View my achievement here – https://coursera.org/share/2a76acacc545200340a2a959670ec002
View my achievement from Google on Coursera – https://www.coursera.org/account/accomplishments/certificate/WNENVHT8TCQQ
- Confirmation bias :- Your prior (vague) knowledge or beliefs influence your judgement. You think you know this already. because of preconception
- False consensus bias :- Believing your own choice as a choice of group. Overestimating that a large number of people will agree to your judgement
- Recency bias :- You subconsciously believe that the most recently/last heard/discussed idea is the best
- Primacy bias :- You tend to believe/recall what you heard first (may be from a first speaker) is the best. You don’t remember or don’t care what later said because the first speaker made strong points.
- Implicit bias :- You subconsciously choose a set of people to interview, because you are comfortable with them.
- Sunk cost fallacy :- You will tend to keep the same ideas/work/investments, because you already invested in it.
Theme source: UX Design course by Google
View my achievement here – https://coursera.org/share/a39d3c723d92aee59857b71e11c7135a
This is my second badge, after Enterprise Design Thinking Practitioner. Thank you IBM for such a great course.
View my achievement here – https://www.credly.com/badges/5dbb6279-a3b0-44d1-bdaa-933f7ef82974/public_url
The problems and solutions are an ongoing conversation of, the continuous cycle which consist of: Observe, Reflect and Make.
- Focus on user outcomes (Pur users first. Measure by how we fulfill user’s needs. Know the difference between users and clients.
- Restless reinvention
- Diverse Empowered Teams
Three techniques for diverse teams to reflect together as we move from idea to outcome.
- Hills – Statements of intent written as meaningful user outcomes.
- Playbacks – Bring stakeholders into the loop in a safe place to ell stories and exchange feedback.
- Sponsor Users – Real world users, who contribute their domain expertise to your team.
Observe: Ask each other
Reflect: Ask each other
Make: Consider these questions
An answer of definite YES or NO is highly irrelevant here, because a Microservice can be written in any programming language which supports some communication end point, such as API.
A Microservice is an application architecture style and the programming language used is just one element of it. Let us revisit Martin Fowler’s definitions from 2014,
…a particular way of designing software applications as suites of independently deployable services
…developing a single application as a suite of small services, each running in its own process
…which may be written in different programming languages and use different data storage technologies.
Not all Microservices need to follow all the characteristics defined by all the experts in the field, but at least we have to make sure it is not violating any characteristics.
There are different deployment options available such as Kubernetes, or Azure Container Service. They use a concept of removing-the-bad, and spin-up-new containers. To support this process, it is important to make sure our microservice applications are independent and stateless to avoid any application crashes or malfunction.
Coming back to our question of programming languages, while we can use any languages or technology stack for writing Microservices, it is always good to keep these points in mind while selection:
- If not necessary, try to avoid languages which requires a virtual machine to run..such as JVM for Java. Some memory resident platforms require some bootup and killing time which can delay the instance creation and destroy. Found Go handles is better.
- Smaller the better, the container size matters. Some languages require a bigger library to be accompanied to have the application work properly, but it makes the container size bigger.
- Application performance – some programming languages are faster for some operations compared to others
Well, it all boils down to the functional and technical requirements, and I do believe that the selection of programming language is not crucial for most cases. Upon Google research, it is also found that people rely/biased on their own skillset to build Microservices, than making the choice-of-language a problem in front of them, which makes this question a low priority concern.
Read about Microservices here – https://martinfowler.com/articles/microservices.html
Microsoft Cloud Adoption Framework is basically a collection of guidance, best practices, tools and techniques to be followed by various technology business and technology stakeholders in the organization to make sure they build and maintain the best possible platform which ensures security, governance, scalability and other non functional requirements aspects.
While cloud adoption gives 80%+ of benefits compared to the traditional, or legacy on-premise data center infrastructure way of life, as a public platform, it also introduces few points of concerns to business leaderships such as Security. Years back when the cloud service platforms were initially introduced, the banking and other financial firms had trust issues because there were multiple levels of organizational hierarchy to be convinced and technical knowledge level is different from person to person. But today, it is not anymore an issue because we have multiple cloud providers in the market providing cutting edge solutions to solve each and every problem of the customer and no significant breaches were reported, and more importantly the cloud literacy level of people also rose.
Here is where the Cloud Adoption Framework plays its big role in helping people, process and the technology. It defines a clear and practical roadmap to the cloud that is foolproof and quick enough to give businesses the expected result and smooth transition.
Below are the main stages in the roadmap as per Microsoft Cloud Adoption Framework:
- Define: We start the journey by defining a business case, followed by a cloud adoption strategy. We set our vision, key drivers, objectives, and justification inline with the organization vision and other aspects such as financial and technology parameters. We set the expectations and document the need at this stage. The motivation for a cloud adoption decision could be because of upgrading technology, business expansion, cost, reducing complexity, operational efficiency, customer experience, faster time-to-market, or business agility.
- Plan: Create the cloud adoption plan. This is one crucial phase where we have to plan the communication model, security, monitoring etc. Cloud readiness and adoption plan will be crystal clear at this point. Most cases would require a platform/application/infrastructure assessment and gap analysis for effective planning, especially for enterprise level applications. It is recommended to have an incremental implementation approach for larger projects. Approaches taken for migration for each application or service could be different. Several approaches are in consideration such as Rehost (lift-and-shift), Refactor (like splitting functionality to multiple chunks for maintainability), Rearchitect (like converting monolith to microservices architecture for scalability), Rebuild (dump unused functionality/applications and build new), and Replace (discard the old applciation and make everything new). For the business continuity, you might also plan to have the coexistence of legacy and new platforms for a short/evaluation period, not just to evaluate the efficiency, but also to help the staff and customers a smooth transition.
- Ready: We set the stage, aka Landing Zones and prepare other cloud infrastructure dependencies here. This phase also includes the validation of the architecture, and patterns & practices. As part of the process, team will address the issues identified while gap analysis, prepare team (eg. by providing training), and establish mitigation/support options.
- Adopt: Action phase! We do the migration/modernization of platform and depended applications. We also may do the cloud native transformation if planned earlier. Migration to PaaS services or introducing DevOps/DecSecOps/DevSecTestOps can be in the scope.
- Govern & Manage: Time to set benchmarks, compliance, rules, protocols, risk tolerance levels, mitigation plans, monitor, audit, and manage. Governance & Manage are not really phases, but a continuous monitoring and improvement process.
Read more on the Microsoft Cloud Adoption journey here:
Find some of the benefits of Microsoft Power Platform.
- Self-Service for Easy Adoption and Use
- Can be used by most kinds of users (business, executives, developers, BAs)
- Rapid prototyping (no need to remake)
- Saving time for development
- Reducing third party dependency
- Integration with third parties, especially Microsoft tools such as one drive, excel, teams
- Device compatibility (work across devices)
- All Enterprise Business Processes in a Single Platform
- Compliance, Governance, Scalability, Security, Disaster Recovery
- No software upgrade, patching headaches
- Microsoft Advantage
- Office 365 Integration
- Enterprise Scale
- Large set of connectors (data source support)