TQ
dev.com
Blog about software development
17 Oct 2018 - by 'Maurits van der Schee'
All product companies have monoliths. They have many advantages, but they fail when scaling up and out. Most companies are moving to microservices. But microservices fail to protect data quality. The solution is the dataservice architecture as described in this article.
Monolith architecture fails to formalize responsibilities and limit dependencies between software teams. Microservice architecture fails to ensure data quality as transactions and consistency checks are absent. Dataservice architecture will solve both issues.
In this architecture teams have three kinds of services: "data services", "logic services" and "render services". This sounds like microservices, but there is a subtle difference. It actually resembles the MVC structure of a monolith. The data services expose the data structure with a security model. The logic services connect to multiple data services and do not have their own storage (but may have cache). The render services combine JSON sources to output HTML. Not that you may have multiple data services, but that they do have to operate on the same database. Data services produce JSON and so do logic services. Render services on the other hand produce HTML.
When you change the data structure you need to conform to the DBA guidelines. These are pretty simple. Do not use natural or composite primary keys. Use foreign key constraints and add indexes to foreign keys. Unstructured data is not allowed. Meta constructs, such as "entity" and "property" tables are not allowed either. All tables are owned by a single dataservice (store the owner in the table comment). You may not have cascading updates between tables owned by different data services. You will need a DBA, because having a clean data model is the key to high quality software.
When implementing multiple services you need to standardize on a stack and not just any stack. You need the stack that brings most value to your software. Software architects have to deny the usage of technologies that are not needed or not known as the industry's best practice. For instance, a Java shop should have very good reasons not to use Spring Boot, Hibernate and JSP. Architects are needed to counter the arguments that developers (and sometimes managers) make for using the latest and greatest (hyped) technology.
Developers and managers have perverse incentives to use complex solutions and lots of people for simple tasks. This is what is often referred to "Resume Driven Development". It means that people argue decisions with the contents of their resume in mind. They do not aim for maximizing software value at their current employer, but optimize for a higher salary at their next employer. The DBA and architect need to control this. Unfortunately most companies will have zero incentives to reward this type of quality control. This means that the DBA and architect lose and the developers and managers win. This results in software that is a big ball of mud and that require heaps of developers to make minor changes in.
Recognize this problem?
PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.
Subscribe