Sean Farmar
Distributed Systems Expert
Wicklow, Ireland
With over 25 years of experience, Sean Farmar specializes in providing simple solutions for complex business requirements applying SOA and distributed computing principles inspired by Udi Dahan.
Sean runs Bosca Software Solutions Ltd. a boutique consulting company providing management and technical consulting related to product software engineering, custom project delivery, and training.
Area of Expertise
Topics
Understanding The Business Problem
One pattern I see again and again in software projects is related to the interaction between the business and the developers.
There are a few aspects to this, but one of the challenging ones is focusing on the solution instead of the problem the business is trying to solve, and this is done by both the business and the developers.
Another aspect is how well we, as developers, understand the business domain, mostly if we want to engage in Domain Driven Design.
In this talk, I will try to explain why it is so important to understand the business domain and the business problem we are trying to solve.
To Re-write Or Not To Re-write
You might have been there before, the system is dying, it got to be a big ball of mud, making changes is risky, time-consuming and horrible...
You go to your manager and say, we can't go on like this anymore! Your manager asks, so what are you suggesting?
And your answer is: we need to re-write!
Now, most of the time and as a role of thumb I would say NEVER go to a re-right: it will take years and you are most likely to end up with two systems the new one and the legacy one running side by side, if you thought your legacy system was a nightmare to maintain, now you have twice the grief :-|... But there are scenarios when this can work.
In this talk, I'll share my experiences with re-writing a system and when it does make sense to go for it.
SOA lessons learnt (OR Microservices done better)
Service Oriented Architecture has been around for a while, now Microservices is the new black, that’s cool, but can we learn from when we failed and succeeded implementing SOA? There are some really useful lessons we can take and avoid the pitfalls.
Using DDD To Decompose Your Monolith
Software design is hard, maybe the hardest part of building software systems...
When designing distributed systems things get even more challenging.
Now that Microservices are so popular, we all want to decompose our monoliths to smaller units of independent components. If we don't want to end up with a distributed monolith, we need to have a toolbox of design concepts so we can achieve well-defined boundaries between our components groups described as "Services" and "Service Boundaries" in the Service Oriented Architecture or SOA paradigm.
The traditional way of designing systems based on a domain data model with very complex relationships and dependencies may kind of work when building a monolith, but just breaks apart when you building distributed systems.
One of the pillars of distributed system design is to solve the **coupling** problem.
If we look at the tenants of SOA they all address coupling:
* **Explicit Boundaries**: In it's the simplest form it is to find what belongs together and making sure there are no leakages between the defined boundaries of a "Service".
* **Autonomy**: Like in Object orientation, Keep our components and "Services" autonomous, encapsulated and have as little dependencies to the outside as possible.
* **Sharing schema and contracts not classes**: Make sure we don't introduce coupling by using an open protocol for communication.
* **Compatibility based upon policy**: This is the hardest tenant to articulate, but again, it's about loose coupling, an explicit API that describes the component's behaviour.
In order to achieve this, we need to rethink how we design our components and "Services"
We need to move from monolith thinking to distributed thinking, leaving the single relational data model to multiple vertical bounded contexts that together compose a "Service" boundary.
In this talk I will walk through the process of designing a very simplistic and naive vertical slice while introducing the concepts from Domain Driven Design (DDD) and SOA, to build a single vertical, from there you will be able to do your first steps to design a loosely coupled distributed system, and be on the way to find you "Service" boundaries.
Why DevOps and Microservices are a great fit?
You want to do DevOps and move fast using continuous delivery but your architecture is holding you back. In this talk, we will look at how a microservices architecture is essential to make DevOps and CI/CD successful.
We all want to get out of the rot of traditional SDLC, waterfall, big ball of mud...
We want to be faster, more flexible, providing more value upfront, WINNING 🙂, have short feedback loops, be able to work in small cross-functional teams.
To do that we want to be able to do continues delivery and continues deployment which leads us to what is described in the DevOps handbook...
To do that:
You should be able to reliably (tested, secure….)
Deploy small units of work to production (reduce the risk in deploying new code to production (roll forward, blue-green ))
Have many teams work in parallel autonomously across the system functions (business).
Decrease lead time of features and bug fixes to production.
This is all well and good but when we try to get there we keep getting pulled back by our architecture.
When we look at successful DevOps transformations we see that architecture is one of the significant factors of success.
In this talk, we will cover Identifying boundaries, monolith decomposition and bounded contexts and how we can build better microservices so our DevOps will be a win 🙂.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top