Today, we are going to take a look at something a little different. We are going to talk about workload criticality, methods to assess how critical your workload is, and the ramifications of that criticality in terms of the Cloud.
PoC, PoT, Prototype, MVP, Pilot - what do they all mean? What is the difference between them, and when should you use them?
Today, we are going to take a look at a technical Cloud Product Development lifecycle - in my eyes, understanding these terminologies is key to determining:
Cloud Design patterns help build reliable, scalable, secure applications in the cloud.
Today, we will cover common patterns, their use cases, and considerations.
The patterns we will cover today are only a small set of common patterns documented in the Azure Architecture Center.
Troubleshooting Azure Open AI and API calls to OpenAI can be challenging, especially when you may not know where to start!
The idea of this article is to give you not only a place to start with some common scenarios you may run into but also a way of thinking - to help you troubleshoot. This is not a technical 'get-your-hands dirty, delve into those logs' type article.
I am a big fan of the KT, or Kepner-Tregoe problem analysis methodology, and I have used it in many scenarios throughout my career to help discover and test the root cause of various problems. So, we will use the base of this problem analysis methodology to help us troubleshoot the scenarios we will discuss in this article.
Being a 'Technical Lead' or 'Tech Lead' means different things to some people and organizations; based on definitions found online, a Technical Lead is:
"A technical lead is a professional who oversees a team of technical personnel at a software or technology company. They often lead software development or software engineering teams and troubleshoot technical issues that involve software development, engineering tasks and product releases."
Although I agree with this, I would flesh out a bit more around architectural governance (or technical assurance, which is what the problem this role or function is for) across it - it also doesn't need to be software development heavy; it can sit in the operational and delivery spaces as well (waterfall or agile) and is more than a specific role, but a frame of mind.