About the topic: Wix transitioned from monolith to microservices around 8 years ago. Or did it? We have hundreds of microservices in production with teams working on separate independent services or groups of services with decoupled deployments and SLAs. Sounds like a microservice architecture, but there is a dark truth to it – single platform (jvm), shared libraries (framework), fat clients (binary dependencies). In industry it is called a distributed monolith. There is no easy way or incentive to get rid of it. But there is a way! Let me tell you a story on how much fun it was, what path we took and where we are now with getting to a proper polyglot microservice architecture. John About Vilius: Guild Master @ Wix with experience in different roles and companies (enterprise, start-up, you name it). No matter how much life/circumstances are pushing me to lead/management roles, I always find ways to come back and keep on hacking. Twitter: https://twitter.com/viliusl GitHub: https://github.com/viliusl

1. Decomposing
distributed monolith with
Node.jsVilius, Software Engineer
linkedin/viliusl github.com/viliusl@viliuslviliusl@wix.com

2. Decomposing
distributed monolith with
Node.jsVilius, Sofware Engineer
linkedin/viliusl github.com/viliusl@viliuslviliusl@wix.com
Stack of your
choice

3. Hi.
I am Vilius
Lithuania
Ukraine
Vilnius
Kyiv
Dnipro
Wix Engineering Locations
Israel
Tel-Aviv
Be’er Sheva

4. Hi.
I am Vilius
Lithuania
Vilnius
Wix Engineering Locations

5. AGENDA
Microservices and Distributed Monolith
(DM)
Why am I talking about DM in first place?
Short history and joys of adding 2nd stack
Decomposing Distributed Monolith

6. “Microservice architectural style is an
approach to developing a single
application as a suite of small services,
each running in its own process and
communicating with lightweight
mechanisms, often an HTTP resource
API”
Martin Fowler

7. What is a
distributed
monolith
01

8. A form of a binary coupling, when in
order to interact and coexist in a
given system you are required to
use a set of “official” libraries.

9. Client library becomes “Only” official
way to access the service

10. What’s wrong with it?

11. Nearly impossible to adopt new
architectures, languages, etc.

12. But hey, DRY, code reuse - it’s good
right?

13. “The evils of too much coupling
between services are far worse than
the problems caused by code
duplication”
Sam Newman, Building
Microservices

14. You potentially lose
 polyglot;
 organizational/technical decoupling;
 temporal decoupling;

15. Ok, so what is an alternative?

16. Contracts and protocols!

17. Yeah, but central logging, distributed
tracing, context passing….

18. You don’t need binary coupling
 Standardization via protocols and contracts and independent libraries
 Compliancy/contract tests

19. Why am I talking about
Distributed Monolith in the first
place?
02

20. Let’s answer to 2 following questions
honestly

21. Does it take months to upgrade a
library across company?

22. Does it take months to upgrade a
library across company?

23. Does it take ~ a year to introduce a
new stack?

24. Introducing a Node.js stack @
Wix
03

25. “Target or this project is to enable
coding front-end servers in Wix using
Node.js. We are aiming at the
pattern of front-end servers and
service-servers – a pattern that is
used in different companies”
Yoav Abrahami

29. Does not look too hard right?

32. But wait, there is more…

35. Oh, and ops contracts…

37. But not all is gloom and doom

38. Build/Deploy pipeline* already had
support/extensions for non-official
stack
*lifecycle, fryingpan, teamcity

39. Contract for deploying application
was defined, sane, simple*
*https://kb.wixpress.com/display/system/Docker+image+deployment+requirement

40. Contract for configuration was clear
and defined*
* https://kb.wixpress.com/display/chef/Wix+Artifact+Config+Templates

41. Underlying protocols were
standardized, business services as
proper microservices

42. Decomposing Distributed
Monolith
04

43. There were never a goal to
decompose, fix, re-architect existing
stack

44. The goal was to introduce new one
to be leaner, be faster, make us go
faster

45. Decomposition is just a side-effect if
you want to actually be leaner, go
faster

46. Step #1 – just do it!

47. // todo - talk to Vilius about that
var url = req => req.protocol + '://' + req.get('host') + req.originalUrl;
// todo - add petri enricher
return new WixRpcClientSupport(
reqContext.get(wixRequestContext),
rpcSigner.get(options.rpcSigningKey),
wixSessionEnricher.get(wixSession),
biEnricher.get(wixBi)
);
module.exports.addTo = app => {
app.get('/health/is_alive', (req, res) => res.send('Alive'));
};
Some TODOs

48. Proxy APIs for fat clients

49. Cover bare-minimum to run in
production

50. Step #2 – we got noticed!

52. const {expect} = require('chai'),
testkit = require('./support/testkit'),
http = require('wnp-http-test-client'),
jvmTestkit = require('wix-jvm-bootstrap-testkit');
describe('petri client', function () {
const app = testkit.server('petri').beforeAndAfter();
const jvmTestkit = jvmTestkit.server({
artifact: {
groupId: 'com.wixpress.node',
artifactId: 'wix-spjs-test-server'
}
}).beforeAndAfter();
it('should conduct AB test', () =>
givenABTest('scope', 'anExperiment')
.then(() => conductExperiment('anExperiment'))
.then(res => expect(res).to.equal('true'))
);
//...
});
Test-kits based off
of a core platform
 RPC
 Petri
 Session

53. Step #3 – time to get serious –
compliancy tests are born.

54. Platform agnostic

55. "health monitoring - protocol" >> {
"/health/is_alive responds with failure" >> {
healthTestDependency.becomeUnavailable()
eventually {
queryIsAliveAPI must beUnavailable
}
}
"/health/is_alive responds with success" >> {
healthTestDependency.becomeAvailable()
eventually {
queryIsAliveAPI must beSuccessfulWith("Alive")
}
}
"health tests executed with three retries" >> {
stabilizeInHealthyState()
healthTestDependency.becomeFlaky(consecutiveFailures = 1)
holds(samples = 100, sleep = 50.milliseconds) {
queryIsAliveAPI must beSuccessful
}
}
Generic tests
 Using testkits;
 Platform-agnostic.

56. class NodeComplianceE2E extends BaseComplianceE2E
with HealthAll
with SecurityAll
with I18nAll
with PetriAll
with BiAll
with WebAll
with NodeMetricKeys
with NodeBiKeys
with RpcAll {
LogbackTestHelper.initLogger()
override protected def systemUnderTest: MainService =
new LocalNodeService
}
Easy to add another
stack
 App with exposed
APIs
 Adapters
 Runner

57. What is a contract and what is not?

58. Isn’t it like… monolithic?

60. We are at the junction

61. Proxy

62. API’s and compliance

63. So that we could pass a Litmus test

64. “can I actually take a team of
engineers who are interested in X
becoming a legit thing in my service
and actually build something without
convincing the rest of the company?”
Ben Christensen,
Facebook

65. Thank You
linkedin/viliusl github.com/viliusl@viliuslviliusl@wix.com

66. Q&A
linkedin/viliusl github.com/viliusl@viliuslviliusl@wix.com