 So tonight, we'd like to share what we have learned from our micro-services recommendation. Oh, for recording. Oh, for recording. Okay. Sure. Okay. Right, so there's something good, something we never expect. And the lessons we learned from the trenches, the challenges, after our time in the laterals. Well, we took some practice to overcome them. I have no idea actually. Is this wrong one? Do you want to try this one? Yeah, no problem. So this is for the recording, if you need to. Oh, so it's the micro-services. Okay, so why don't you keep this one? Oh, it's the micro-services. Okay. And then use this. So this is the one, right? Okay. Okay, so tonight, there are some things very good. You know, we learned and some challenges and some practice we took to overcome them. So we'll be sharing today, right? Oh, be slow, okay. Okay. Right. Today, status quo is no longer an option for any business, right? We either disrupt our own business model or we'll be disrupted by our competitors, right, to survive in this digital era. Our studies show that by 2020, 70% of organization worldwide will be disrupted or in the middle of disruption, right? For Singapore government, we actually plan to transform and digitalize all our services by 2023, right? IT is no longer just a support function. It's going to be our key drivers to disrupt and transform our business models. So our CIO and CTO is going to be our best friend of CEO, right? Like what CTO is, what CFO is doing today, right? So we are very fortunate to live in this digital era and but we need a mindset change. Okay. For MOE and ICEAB, right? We are also in the continuous effort to disrupt and transform our business digitally and intelligently. The system we are seeing on the screen is actually our ICEAB examination and assessment system today and tomorrow. For people who are not knowing ICEAB, ICEAB is Singapore Examination Assessment Board. It's a statutory board under MOE, right? The current system is actually being used by primary, secondary and JC, total 369 schools and 28,000 teachers actually using this system to conduct a national exam, like GCEO level, N level and A level, right? Even the PSLE, which is released today, right? So every year, ICEAB and the school actually took about 284 Mondays to conduct the exam and estimate about 1.7 million papers on the scripts being marked in over 49 marking centers, right? So over the years, this system is actually becoming a tele-couple. It's actually showing the high dependency among each other. ICEAB and MOE challenged the status quo. Actually, we start to transform this system into an integrated, more efficient, more cost-effective, better user experience and even more digital capabilities. If you can see from this, oh, shit. Okay. You can see here we actually have, we already have the digital answer scripts and digital marking, digital screen marking, right? It's actually support up to 11,000 markers concurrently to do the marking, right? It's a platform. It's going to be a better and faster services to the public, right? So to make this digital transformation a reality, modern design and modern engineering practice will be required in the HSUI, which allow us actually to continuously innovate on the exam service, also continuously allow us to unlock the exam operation effectiveness and the efficiency, right? Design thinking will make our new system, you know, customer centric and agile and product model will allow us to start small and from a minimal variable product to iterate quickly to approach to the angles, allow the way we also have agility to adapt to the any unforeseen, you know, landscape change, right? Mobile and cloud first will allow us to actually reach out to our customers faster and closer than I want through the multi-channel and the multi-touch points. With API and microservices, right, approach will allow us to actually break the complex system into multiple microservices at a different levels. We can see we actually have a system of engagement, which is the engagement channel to reach out our public users. And we have a system of write costs, right? It's our backbone system. It's a single source of tools for the backend examination and assessment data, right? We also have a system of insights, right? This is actually allow our public officer to use the data-driven approach to build a 360 view, understand what is going on and where we can further improve. Right? The example we are seeing right now is actually a microservices design for one of our system record system called exam. So it's integrated examination administration system. In this microservices implementation, SCAB adopt a domain-driven business and the reusability first approach, right? To actually further decompose the system into a multi-multiple microservices at the higher business level. At the local technical design level, we actually make use of SPA, share nothing at the database, and the services should only communicate via API to decouple the services, right? We also actually make the microservices to be future-ready. For example, if you can see from the screen, the exam candidate services, exam personnel services, right? We will be further reused once we start to build a candidate portal and that exam personnel portal, right? So, aside from that, we also stick to the single source of tools like cohesion on the service level to get our lower level service design, right? Apparently, there are so many values from microservices to the business, right? It actually allows us to allow each of the microservices to evolve independently because we are able to break the system into multiple services. It gives us the flexibility to actually evolve, actually implement differently and independently. The changes from each of the services actually can bring the minimum impact to the others because each of the services is actually a single source of tools and it actually has a complete of the business process and data. So, it absolutely changes from others. Granular microservices can be further reused for the future business needs like what I mentioned just now, candidate portal and exam portals, right? It's also ready for future API integrations and because each of the microservices can actually be built with different technology and different tools, we are free to choose the best technology suit the business and make the services to do the work in a safe and fast way, right? So, in future, if there's a need for us to replace any of the microservices, we also have a choice to replace these different technologies, right? So, the loose couple services actually also allow us to iterate more quickly than ever to bring out the business value faster, right? So, we talked about so much about microservices. Today, microservices is actually becoming overloaded and confusing software engineer term. So, what exactly is a microservices? In Gavtech and MOE, we believe having one common understanding of microservices is critically important. It's actually ultimately help the team to pick up the velocity in the service journey, right? So, we believe microservices is actually an architecture. It's actually allow a collection of loosely coupled business services to come together and form an application, right? Each of the services have to be a single source of truth focused on one purpose, do it well in the sense of you have a complete business process and data to maintain the high coefficient. So, if this sounds very fluffy, actually, we just need to remember three things or three principles, right? Loosely coupled among the services, single source of truth and high cohesion within the services, right? This is going to be the three key principles for us to design a microservices and decide whether this is a microservices or not, right? So, if monolithic app is one cookie on the left, right? So, microservices is going to be something like on the right and it actually break the cookie into multiple pieces with no outer boundary and no constraint the individual services growth and movement but come together, they work the same as a monolithic app, right? So, today, in terms of implementation, we still need to implement the real business logic like how we did in the past but there are additional set of design and implementation we need to take care for the quality attribute of distributed computing among the network of services, right? So, we like to call them cross-cutting concern implementation, right? Aside from the software, standard software tools and environment we need to use, right? Actually, today the modern engineering practice and technology is also mandatory and necessary for microservices implementation the reason is actually failure among the microservices is really inevitable, right? So, but the quality and the resilience can be designed, can be test, can be automated and can be managed by the recent or modern practice and the technology is like, you know, DevOps, CICD, containers, right? Orchestration and service match, all this, right? So, today, the core challenge to the microservices implementation is elite management or microservices elite management, right? So, elite in the software engineer term actually refers to the non-functional requirements I think Gregor always like to call non-repariments not something not required contrary, they are very important, right? So, there are actually things like scalability, you know, like availability, flexibility, security, you know, capacity, all these things, blah, blah, all these things, right? And those things are very important you know, we really need to take care of them and today in the microservice context we have additional self-elities, right? Aside from the existing one, we need to take care of, you know, microservices elities and our list in the screen, right? So, this is not an exhausted list, right? In your elite list, you should actually cover the full lifecycle of service management, right? And if we fail to, you know, really design and implement them properly, right? It can lead to disastrous situation, even worse than more than the take application, right? So, we've been there, actually we've seen that before, right? We like to give our recommendations and we strongly believe this might be the better way to go. First thing for us is how to decompose the microservice. This is really, really a big challenge, right? So, we recommend people always have a tool approach co-exist in our mind, right? And one is primary, the other one is secondary. Domain-driven first, review, and strangle it later. Take the domain-driven approach to focus on the business process and the business event over the data to decompose the services at the higher business level, right? If, later, right? If we didn't do it properly and we may unsub actually do, actually unsub build a group of distributed, monolithic app with high dependency among each other and actually we repeat the same old stories, you know, dependency or these, you know, cohesion issues, right? And if monolithic app, if monolithic, sorry, if microservices is a living architecture, right? And so to the effort to decompose the microservice. We are very mindful that service decomposition is not one time of effort. We will continue review and strangle it later at right time. So what do I mean later at the right time, right? We actually realize the more microservice we have the more resource we need to continuously invest, right? So check your balance record, balance sheet and how many resources you have and how much time you have before you decide whether you're going to further strangle the granular microservices. Okay, database design and data modeling is also an overlooked area in the microservice design and implementation, right? We actually strongly encourage people or actually sculpt strongly and ask people to use one database schema or one microservices and really enforce this at all costs during the implementation. If we don't really do it well we really have a distributed monolithic app in the end, right? But if we do see some of the microservice or big service have a good chance to be further decomposed into multiple services, right? It's okay to share the database between two or maximum three, right? Otherwise little when we refactor the services we will feel like a big challenge on the independence and autonomy, right? In terms of a microservice implementation model sorry, a deployment model we encourage people to actually have a separate CI CD pipeline, right? And actually package each of the microservices entirely independent from each other For example, we took the Docker technologies, right? In terms of service implementation especially on the logic, right? We recommend people to take a consistent approach especially on the microservice state and data management Each of the services should have a state manager to capture the state and data change in consistent manner, right? And if there's any state change need to be calling across microservices then all the participating microservices will need to implement the support of state change compensation in case any of the services fail, right? In this way we are able to maintain the consistency of data consistency and state consistency across the services Right, so how to maintain data consistency across the services this is really like a challenge for us to let's say ask people to, you know, keep an elephant in a room, right? Sounds very challenging, right? So the reason we feel like very challenging is actually because we have a perception the elephant is a big but in fact elephant is not big because there's baby elephants, right? There's other small elephants, right? As long as they are elephants, right? They came in a room, they serve the purpose, it's good So same principle we apply here for the data sorting and consistency Right, so when we talk about this it's really hardcore, you know, technical term CQIs or these things and data sorting So I need to talk a little bit about CQIs CQIs stands for, you know, command, query you know, responsibility separation CQIs in fact have nothing to do with microservices but microservices make use of CQIs and make it popular CQIs introduce a very simple idea in the service design they actually split the one system into two system you know, command system which is doing update-delay you know, create update-delay and query system it also requires two different data modeling to support the query and the command set of the system In microservices, it's absolutely okay to have a CQIs, to have a split of the microservices but whether to introduce two data modeling I would say, you know, we do it wisely or we do it later, right? We really do it when we see a genuine need for our case, you know, for the business reports and some of the analytic dashboard which is really, you know, need to aggregate a huge amount of data from different services There's no way we can actually retrieve them from API so we introduce different data modeling When we talk about the CQIs we also always come together with event sourcing so event sourcing, we need us to actually create a pan-only, you know, data event store so it needs to capture all these data changers All the microservices will need to subscribe to this pan-only event store to keep the state eventual consistent across the microservices but the question is whether we should actually create an event store to capture a full series of events from all services and make a single source of truth over the entire system is going to be a big data store So the trick is, you know, we can start from small We can start to just capture the business event which are absolutely required to maintain the state change across the microservices And in future, if let's say, you know, your technical team is really ready for that you really have a business requirement to go for it, you know, have a full record of event store that will really benefit you because event store actually helps us to do replaying of the records in case you actually lost the change So come to the elitid management Elitid management is really critical to the microservices' success We... broadly, actually, there are two approaches One is microservices' container manager approach will be implement and manage within the service within the service local customer calls Another one is actually set card proxy container It's actually managed and implemented inside the set card container which is come from the service infra It depends on which service infra we are using If service orchestration is taking place at a container level or even below most likely the elitid management will be implemented inside the customer calls as we can see that the pink box or the customer calls to manage the elitid and we need to repeat the same, you know, customer calls all over again across the services, right? And the other thing is if we do this way our service implementation actually have built-in dependency on the underlying service infra in future we need to move to other platform the portability is not that much but the good thing is there's a lot of working calls out there in the internet you can just search for it and get it up and running in short time So if we happen to use Kubernetes so we are somewhere 1.5 in between it means actually part of the elitid is managed by the service implementation and part of the elitid management is done by the service infra a little better but it's not the most ideal situation or solution I think people already start to talk about service mesh If we are going to use service mesh we are using service actually approach 2.0 The good thing for service mesh is actually a promise to isolate all this elitid management from the service implementation and let the developer to solely focus on the real business needs but the bad thing is there's no industry standard there are many different implementation out there and there's no sign the technology will converge to somewhere so we have to keep on monitoring and the implementation of all these elitids is actually completely encapsulated in set container set card proxies we don't need to do any coding it likely could be just configuration and deployment scripts and our service implementation is really literally have a zero dependency with the underlying service infra Since 2.0 is so good shall we just go straight to the 2.0 the answer is yes and no it really depends it depends on our service strategy if our strategy is all in and upcoming project is so complex it can actually generate many many microservices I would suggest look into 2.0 or 1.5 but make sure we really have experienced stuff in the team and they are going to look out all these look out all the changes different technologies and master them ready to use tomorrow but if our service strategy is that small and the upcoming project is so simple just 2.0 or 3.0 I would suggest start from 1.0 if you have technical team who are good at container and Kubernetes ok you go for 1.5 trust me the effort to bridge knowledge from knowing nothing to service mesh is going to be really more and complex it is going to be always the benefit you are getting from service mesh there are other challenges along the way most of the people actually in the early days of microservices journey microservices are also new to us and people take time to develop an understanding build a common understanding to pick up the velocity people also need to unlearn what they learned in the past like modular, UI, data-driven design and take time to get used to the domain-driven business process, event-driven design model when we try to decompose the microservices we also need to balance the priority and concern from different team we need to decompose them to the right level at the right time so you don't know what right level, right time ask your managers, ask your different stakeholders they will tell you a bunch of my concern, my priority I want to do this, I want to do that I need to balance that and the new functional team will need to acquire a substantial business knowledge in the short time after that, they need to transfer this knowledge to the technical team because today, microservices design still heavily rely on agreement by technical teams understanding this is really a job, honestly because microservices, the first level of microservices design should be business process and event-driven it's no longer data and technology-driven we need everybody come together to create this first level of microservices design before we get into the technical so we need a one-side change in terms of the design process IT or technical people is no longer the driver of microservices design but the key facilitators or the co-pilot at most aside from that, our technical team also have our own challenge we need to acquire a substantial knowledge within the short period of time for the microservices technology there are so many technologies out there today, you've got a Docker container you've got EF, EKS ECS, Azure technology all these things, right? and we also need to keep up with all these different keep up the change and look out for any emerging technologies we need to know where is good, where is bad Pro and cons and we decide where is the practical solution where the practical way up from these delusions dilemmas, right? because we also have a challenge of resource and time and we need to balance different whether the technology is ready or not people is also not a big challenge not many people actually have working experience in microservices a lot of time, you ask them they are actually working their experience is very textbook level they build they build in halls very like, you know, pet store you know, experience but it's good, better than you know don't have, but it's still textbook so there's no working application for us to rely on and draw the experience okay, so lesson learned we recommend everyone to take following practice to minimise the impact to the team right? first of all, we should play thought leadership right, we actually we run we should run microservices, education sessions, draft the design and discovery sessions to bridge the knowledge gap to build one common understanding we we you know, ask people we like to ask people to run the event storming workshop so we can quickly build up the business knowledge to design the first level microservices microservices at the business level and we recommend people to you know, review with all different roles your CIO, your CTO your head of division to understand their concerns priorities, balance them even maybe also moderate their expectations right and for technical team we need to actually keep abreast to the technology advancement push all these new ideas, new features functions and examples to the partners encourage people to actually do your own research engage technology consulting services right and do your own PLC to minimize to mitigate the race on the design and having read people readily available in your team because we actually notice that there's great an emerging area actually there's a gap in between application development team and clock infra team new tier I like to call it service in frontier someone need to actually design the overlay network you have underlying the software defined network but when you come to the microservices you have another overlay network and you need to actually manage properly design properly the service traffic across different networks and you need to do all this design and also need to do the setup depth ops, IAC, container orchestration and all these things you need someone really start to bridge the gap between two teams and the last one listen to your partners and build up women's solutions together with them this comes to my last slide a quick recap as a takeaway for today's sharing services should share nothing and communicate only where API so we can decouple the services bring the minimum impact to the others each of the services should be a single source of truth they focus on one purpose and do it well science doesn't matter don't betray or hijack by the world macro the services can be substantial as long as we stick to three principles what are the three principles loosely coupled among the services single source of truth and high cohesion within the services high cohesion in the sense of we need to have a complete business process and data for the given purpose often time we have challenges in time, resources we need to balance the priority and concerns gave priority to the business over the technical support services remember we deliver business or come not technical improvement macro services is a living architecture we are mindful to review and strangle it later at the right time the key is decompose strangle it to the right level and enough services strangle to just enough services to meet the business in consideration your current team size well play your rich man and poor man strategy really look at your balance shit really look at your resource last one try our best to uphold the service management from service implementation free our developer to focus on the real business needs ok thank you thank you we have a short Q&A session now so wow ok right now you bring oh sorry this one is for the site on the API gateway the micro services in the autonomous clock if there is a hybrid clock or multi clock how about is a good practice between micro services communication is it going through the API gateway ok I think right sorry I just want to rephrase your question make sure I understand you properly you talk about the multi clock whether hybrid or multi clock if you have multiple services and bridge the communication between these two services yes API gateway is one way to do that eventually you just need to let the two system talk to each other whether to use API gateway is your choice you can actually don't use API gateway also fine the key is how many API you have right what do you want to what do you want to achieve with the API gateway API gateway is also a one design pattern we didn't really cover here actually my audience has a lot more because I feel like we may not be able to recover in time it's one of the approach it's actually trying to centralize some of the business logic like authentication, authorization everything all these things do you want to do that if you want to do that you centralize over there if it's just one simple call which you know your benefit really you know the putting the API really benefit your this one API it doesn't make sense and actually you already implement all these things within your local service customer calls okay oh sorry how do you balance both these architectures together because you will still have some monolithic applications that we cannot move out of so technically as well as culturally to you may take to teams to systems because these monolithic applications will continue to be developed right you cannot stop development there okay my the question is how do we maintain should we maintain one team or two teams because we still have a monolithic app and we are moving to the microservices way you know how to break this status code you know technically you can have more kind of applications right so I would not recommend if your system is very complex I would not recommend go straight unless you are very bold right and to the microservices right this strangle pattern you can start from small break your monolithic app slowly actually break up into a microservices right so you just need to in that sense you can make use of an existing team because they know the business well they know the business all the logic there and you can start your microservices journey right and but microservices really require resources so there is a good set of microservices is actually speed speed in the go to market right but the other set of the microservices is we need to pour in the money we need to use right we need to balance it right so and I also have questions okay thank you sorry actually my question is related to performance degradation okay microservices how can we open those challenges if we suppose I am running an API and I see a performance degradation like I am getting a late reply from that API and I used to get a fast reply before that like how can we open those challenges okay that's why modern modern engineering practice come into picture right so a term called observabilities right when we come into microservices we really need to enforce these observabilities right to really understand we need to have API tracing we need to have APM into the application we understand where exactly the bottleneck is right so we can right away pinpoint the problem and go and fix it right we feel we feel fast we need to feel fast and we need to you know response fast right so the key is make use of you know modern engineering practice put in the observability set of monitoring tools right to really help you to pinpoint the problem where is the bottleneck but still even if we find the bottleneck and still our performance is still not better than what we used to have previously right and still shall we go ahead and use those APIs or shall we stick stick to our old logic okay your question let me rephrase your question is you build a microservices and microservices being built properly correctly in place and the problem is the performance is not better than the monolithic app right go back to your monolithic app could you elaborate how you do the reporting with all these microservices and so many databases right so as I mentioned we need to have a different data model right so event sourcing is one way we actually capture all the different business event put into the event store and all the business reports all these microservices we have to listen to these events and register to all these business events whenever there is a change it will be being triggered being informed and they will take down the business events to make the change locally do I answer your questions first of all we need to have a two different data model or two different database right we need to have an intermediate to actually bridge the differences because there are two different data store right so while you make a transaction which is your command set of the system it make a change in your command database right we need to propagate the change to the other set of which is query set right we introduce the event store and your query set of the microservices will listen to the event store whether this event come in and then if there is any event coming you may change locally so it will be consistent but it's not instant consistent it's eventual consistent so every microservice has its own query database iron query database no I don't I say we should do it wisely or do it later it depends on your business requirements right if you can if you can do it within the one system start from small until your business team ready or until your technical team really ready for that because I don't see any you know immediate business requirement for that you are absolutely okay to actually create a command set of the system and the query set of system I introduce two data models but the thing is if you can do it within one database model why do it so that for all the sets of microservices out there there is only a single query database it depends still again it depends your business so flexible you can have multiple query databases or you can have one single one yes you can have one you can have two it depends on really it depends on your business requirements because I'm getting results from all the different databases yes I agree that's why it's an elephant right but you can start from small maybe elephant right depends on your your business requirement your teams ready in us Ty maybe you can approach the speakers after the session thank you thank you all for your questions so much