Yogi Aradhye has been writing code for well over a decade and has worked on many different technologies. His diverse work experience includes small startups to large enterprises such as DELL. Currently, he is leading projects at Headspring as a Principal Consultant, focusing on building advanced distributed systems. Over the past 20 months, he has been a lead architect for a financial services client. He sets patterns and guides multiple teams in a collaborative journey towards microservices. Yogi has also been a speaker at .NET User Group Code Camps in Hartford, Boston, Houston, and Austin. He has also presented at larger developer conferences such as Kansas City Developer Conference and NDC Oslo.
"Monolith to microservices" is not a business goal. Business stakeholders don't care about architecture choices. They care if their customers are getting the optimum experience. Adopting microservices can have business advantages, but many times, companies overlook the disadvantages and tradeoffs. They also underestimate the inefficiencies and problems that are not directly related to the microservices transformation but often hold a project like this back. What goes wrong with them?
In this talk, we will dive into my real project experiences when we helped our clients reign in out of control microservices projects. Having a monolith isn't inherently bad, nor does microservices transformation solely deliver business value. After listening to this talk, you will know why it doesn't have to be a binary choice between microservices and a monolith. This knowledge can leave you equipped to start making improvements right away and achieve a successful transformation.
As organizations grow, they bring different kinds of software systems under their fold. Some are legacy systems, some are state-of-the-art, cloud-based ones, but they all must be integrated somehow. Sometimes there are limits to how many modifications we can make to these systems. Coupling them with direct communication could severely hamstring the organization’s ability to do business activities. How do we make sure these disparate systems communicate effectively in a decoupled fashion at scale?
Turns out, there’s a better way to achieve effective communication than building one on one direct communication. In this talk, we’ll discuss how data streaming with Kafka can help take our integration strategy to the next level. I’ll walk you through the options we have when it comes to streaming and help you determine why Kafka may fit the bill for your needs. Even though Kafka originated in the Linux ecosystem, it has matured quite a bit in its ability to plug itself into many others. We’ll deep dive into how it works in the Microsoft ecosystem. After this talk, you’ll be equipped with the knowledge you need to upgrade your integration strategy by leveraging the power of Kafka.
The autonomy that comes with microservices is very attractive to our customers. Sometimes it starts to become a double-edged sword of sorts. They realize that the power of autonomy comes with a great responsibility for the development teams and the organization in general. The need for a technical ear that hears as many designs as possible arises. Traditionally, that leads to architectural oversight. Then they gather a bunch of senior engineers and call them architects. Things start to get worse because nobody can really figure out what the right level of oversight is. The group gets viewed as an “Ivory tower” that’s always busy in meetings when needed. Now, they have moved smart engineers from coding to meetings, anarchy is breeding and nobody is happy. What’s going on here? What can we do?
In this talk, we’ll take a look at how to break some traditional molds and modernize the architect’s role. I’ll take you through a journey to explore some principles, forged through practice from real-world projects. You’ll learn strategies for mentoring development teams, scaling processes, and maximizing efficiency. With the right structures in place, architects can guide teams into the “pit of success,” as Scott Guthrie likes to put it. Together, we’ll strike down the walls of the ivory tower and raise up a new group of evolutionary architects. We want to make sure architects are viewed as peers and not as 10xengineers.