I first tried building applications with microservices around 2013. That was the year Docker was initially released, but back then, I hadn’t heard about it. At that time, we built an application with each microservice running on a separate virtual machine. As you might expect, that was an expensive way to run microservices. Because of the high running costs, we then opted to create fewer rather than more microservices, pushing more and more functionality into the existing microservices to the point where we couldn’t really call them microservices anymore. It was still a distributed application, of course, and it worked well enough, but the services weren’t as micro-sized as we had hoped. I already knew at that stage that microservices were a powerful idea, if only they were cheaper. I put microservices back on the shelf but made a note that I should look at them again later. Over the years, I watched from the sidelines as the tools and technology around microservices developed, powered by the rise (and rise) of open source coding. And I looked on as the cost of cloud computing continued to drop, spurred on by competition between vendors. Over time, it was clear that building and running a distributed application with micro-sized components was becoming more cost effective. After what seemed like a lifetime, in early 2018, I officially returned to the world of microservices. I had two opportunities for which I believed microservices were the right fit. Both were startups. The first was a contract job to bootstrap a new microservices application for a promising young company. The second was building a microservices application for my own startup. PREFACE xvii To be successful, I knew that I needed new tools. I needed an effective way to package microservices. I needed a computing platform on which I could deploy microservices. Crucially, I needed to be able to automate deployments. By then, Docker had already gained a big foothold in our industry, so I knew it was a safe bet as a way to package microservices. I also liked the look of Kubernetes as a computing platform for microservices, but, early on, I was extremely uncertain about it. Kubernetes, however, promised a future of freedom from the tyranny of cloud vendor lock-in—that was very appealing. At this point, I’d read quite a few books on microservices. These were all interesting, providing good value on a theoretical level. I do enjoy reading the theory, but these books lacked the practical examples that would have helped me smash through my own learning curve. Even as an experienced developer, I was struggling to know where to start! I knew from past experience that bad technical decisions made at the beginning of a project would haunt me to the end. Learning Kubernetes was especially hard. From the outside, it seemed incredibly difficult to penetrate. But I had a job to do, and I needed a way to deliver software, so I pushed on. The going was tough, and I almost gave up on Kubernetes a few times. The situation changed when I discovered Terraform. This was the missing piece of the puzzle for me. It’s what made Kubernetes understandable and usable to the point where I could do nothing else but commit to using it. Terraform is the tool that allowed me to describe the infrastructure of my application. I began writing infrastructure as code, and it felt like I had moved to the big leagues. I forced my way through the learning curve, bolstered by my longtime experience of evaluating technology and learning quickly on the job, with a splash of trial and error mixed in for good measure. My efforts delivered software that is performant, flexible, reliable, scalable, and extensible. Through this time, my desire to write this book sparked and grew to the point where I had to take action. A new mission formed—I wanted to make microservices more accessible. I felt compelled to write this book; it’s the book I wanted but didn’t have. I knew I could help people, and the best way to do that was with a practical book—this book. A book that shows you, step-by-step, that microservices don’t have to be difficult or complex; it all depends on your approach and the perspective you take. You now have in your hands the fruits of that labor. I learned the hard way so that you don’t have to.


Q- how you see the trends of microscies compared to gen ai and llms did you see a more the same pattern where people do not see it and later become more and more interesting it and become cost efficient and more powerful .. all is just a hybe ,

**The Evolution of Microservices and Generative AI: Comparative Patterns and Adoption**

The trends you've observed with microservices mirror the current trajectory of generative AI and large language models (LLMs). Both technologies initially faced skepticism and limited adoption due to barriers like cost, complexity, and a lack of accessible tooling. However, as they matured and became more cost-effective, both gained broader acceptance and demonstrated their value in practical applications.

### Microservices Evolution:
- **Early Challenges:** Microservices were conceptually appealing but challenging to implement efficiently. The lack of mature tooling and high costs (each service requiring its own virtual machine) slowed adoption.
- **Technological Advancements:** Tools like Docker (containerization) and Kubernetes (orchestration) reduced complexity and costs. Infrastructure-as-code tools like Terraform further simplified complex deployments.
- **Increased Adoption:** These advancements made microservices more accessible, allowing organizations to build scalable, flexible, and maintainable systems, leading to wider adoption.

### Generative AI and LLMs:
- **Initial Perception:** Initially, generative AI and LLMs were niche technologies due to computational constraints and the complexity of developing and training models.
- **Rapid Advancements:** The capabilities of LLMs, like OpenAI's GPT series, have significantly advanced, showcasing abilities in context understanding, human-like text generation, and a range of language tasks.
- **Accessibility and Cost Efficiency:** Cloud computing and pre-trained models have made it easier and more affordable for organizations to use generative AI without needing extensive resources for model training.
- **Growing Interest and Applications:** LLMs now support industries through applications like customer service chatbots, content creation, code generation, and data analysis, leading to increased interest in adoption.

### Comparative Patterns:
- **From Skepticism to Adoption:** Both technologies initially faced barriers like cost and complexity. As tools improved and costs dropped, adoption grew.
- **Tooling and Infrastructure:** Just as Docker, Kubernetes, and Terraform transformed microservices, AI development platforms have lowered the entry barriers for generative AI.
- **Cost Efficiency:** Advances in cloud computing and hardware (GPUs and TPUs) have reduced the costs of running large-scale AI models.
- **Industry Impact:** Microservices have transformed software architecture, while generative AI is impacting industries such as healthcare, finance, and education.

### Hype vs. Sustained Value:
While both technologies have been subject to significant hype, they offer real, lasting benefits:
- **Microservices:** The sustained adoption of microservices highlights their value in building scalable, maintainable systems, improving deployment agility, and resilience.
- **Generative AI and LLMs:** Despite the hype, LLMs are proving their utility. However, challenges like ethical concerns, bias, and the need for large data and computing power persist.

### Conclusion:
Both microservices and generative AI illustrate how innovation often follows a path from early skepticism to broader adoption as technologies mature, become cost-effective, and demonstrate tangible value. As generative AI and LLMs continue to evolve, we can expect ongoing improvements in efficiency, accessibility, and cost-effectiveness, indicating that they represent more than just passing trends—they have the potential for lasting industry impact. 

Understanding their long-term potential and practical applications is key to harnessing their full value.

Q- do i need to learn them both give am in my last year and i want to get a job and good curry 
Do i focu in cs theory and basic (like leetcode , databases , netwokrin , security … ) and then choice one filed to master it (either mircroseice (front-end & backend & devops) or ai&data (ai , data science , research parers , python nerds , mlops ) 

What your advice for me given i live in tunise not a tech hub and i want to relocate one day by my skills