There are some huge challenges at Big Silicon Valley companies, like Netflix and the need to scale. But should you really get drawn into that? Sometimes the most complicated issue in development is the business logic, and Bernd Rücker is talking about these challenges at Voxxed Days Vienna this week. We asked him what the complications and challenges are beyond the stack.
What is missing in the typical ‘Silicon Valley stack’?
During the last few years, I regularly heard arguments like “Netflix does not need an orchestration layer, so neither do we.” Especially when looking at modern paradigms like e.g. microservices, people tend to look at the big Silicon Valley companies like Facebook or Netflix. But comparing your own company to the internet giants is a bad idea, especially if you ignore the fact that your business is structurally different from theirs.
Take Netflix, the business model is fairly simple (compared to their size). Users can select one of three on-boarding options, afterwards they pay a monthly fee and can access the service. So implementing the business process of registering a new user is not too complicated. You might get along just by hard wiring some services. Most companies I know have much more complicated business processes! Getting a new insurance contract involves a lot of risk checks, data takeover from the prior insurance company, legal requirements and so on. Shipping a mail order involves not only payment, but also the shipping of goods and handling of returns. Implementing these processes without orchestration is not a good idea.
However a lot of people are still frightened by orchestration, because a lot of mistakes have been made in the past. This can lead to the misconception that orchestration engines are inflexible monoliths, that don’t fit in modern architectures and microservices landscapes. This is a huge misconception, and we need to overcome it. In my talk at Voxxed Vienna I will show how orchestration can be done right in order to fit modern architectures. I will also cover why this results in much cleaner architectures, where changes are easier to implement.
Fun fact: the week after I handed in the talk, Netflix published that they use an orchestration engine, so they also recognized this missing piece in the stack 🙂
Should developers focus more on business logic than technical requirements or middleware?
I think developers should decide what they want to do. One option is to focus on middleware and all the hardcore technological challenges around that. Then they should work for middleware vendors. Or maybe the mentioned internet giants who have a habit of implementing middleware on its own. In “normal” companies, these tasks are pretty limited and will further vanish, if you look at the trends around cloud.
The alternative is to focus on business logic and implement business requirements. By doing so you still have to know how to code, but other disciplines (especially being able to communicate with business stakeholders) are far more important. As systems get more and more connected and complex, there is a lot to do in this field. But yes, these developers should indeed focus on business logic, and for goodness sake, don’t develop your own middleware as a side project while doing so!
What solutions help with the complexity of business logic?
First there are a lot of frameworks and libraries that hide technological details from the developer. This is great! After a quick google you should be able to persist your first entities in a database. Then show them in a responsive HTML5 web application – all without too much prior experience required.
On the other hand, there are methods to help business folks collaborate with developers. Personally I worked in the field of workflow and business processes for over a decade. So I am a big fan of graphical process models, that are directly executable, but also “developer friendly”. Let me explain: I do not believe in the “zero-code-approach”. This is the idea that business folks draw an executable process without involving IT, that can directly be executed. However it does make a lot of sense to model the business relevant aspects (best: business and IT together) and make it executable by adding technical attributes or code. While doing so you can still use your normal development environment and practices. That’s why I call this a developer friendly approach. This helps a lot! Especially the more complex the overall systems get.
A good friend of mine once said: “It’s great – I went into requirements engineering 10 years ago, just because the developer life was so much low level hassle. With what you can do today, I can concentrate on implementing business logic, so I can come back to coding” 🙂
For more, see Bernd’s talk at Voxxed Days Vienna: