MCPA MuleSoft Certified Platform Architect Level 1 – Getting Production Ready

1. Development Lifecycle

Hi. Welcome to the new section. In this course, in this section, we will focus on how to get the things ready for the production. So, the objectives of this particular section are we will try to see what is the development lifecycle of an API which anywhere we have seen so far across the course. We have traveled into lot of phases till this getting ready to further production section. Right? So we have seen already the different aspects of the development lifecycle of an API. But we will just look one more time how it fit together so that we are ready for moving things into the production. We see how DevOps plays the role for helping the things to smoothly move into the higher environments using various tools and their features. We will also see how to design automated tests and all for the APIs so that they work effectively in the API Led connectivity.

And we identify various factors involved in scaling the API performance. And we also see how to deprecate and delete the APA versions in Any Point platform. All right. Now let us move on to the first lecture in this particular section. Let us understand the development lifecycle of the API. As you know, the Mule Soft proposed lifecycle for developing the APA Led connectivity and the integration solutions is the API first approach. Therefore, it all starts with APA Centric activities like creating the APA specifications, interfaces like Ramls and Ramble fragments, etc. And then we proceed to building the API implementations, the actual code. And then we transition into the production by deploying the APIs and the API implementations.

Right? So each of these three phases is supported by Any point platform components which you are seeing in front of you now. So the diagram, what you’re seeing clearly shows that across various phases of the lifecycle of API, what all components of the Any Point platform helps you to achieve them. For example, for designing the API we have the APA Designer component. And then for Prototyping, you have Mocking service and the Flow designer, right? So you can actually, without implementing the full API functionality, you can mock the API which you designed to see the behavior, how it’s working. Correct. And for validating, we have API Console where others can come in and try the stuff which API is offering and see the feel of the API and experience it. Then, for publishing the assets, we have Any Point Exchange where the designed and the prototype API assets are published so that they are discoverable. And the same API, Any Point Exchange is used for getting the feedback as well from the consumers or clients.

They can discover them, find them, try it out and give feedback. And once the APIs are there, in order to operate them, we have APA Manager and Any Point Analytics. Right? APA manager is the place. We create APA instances to manage it by applying various policies for NFRS and all we develop the code using the Any Point Studio, which you already know. And for testing’s sake, we use Mm unit, which is the popular one. There are many other tools as well, but Amunit is the Mule soft component that is offered. Finally, we deploy the code onto the Runtime Manager where we manage the deployed components. So these are the various Edpoint platform components that help us during this APA centric development lifecycle. What you are seeing in front of you now is a more process centric depiction of the APA development lifecycle which we have seen in the previous picture. So this is a more process centric way to represent the same thing. So what you can see is like according to the process centric manner. First we have to design and publish the APIs via Design Center and Publish to Exchange. Then they have to be shared to the end users so that via Exchange they discover them, or through Public Portal, they discover them and they work on it.

They mark it or test it and give the feedback. We register the APIs on the APA manager. Then we pair the APIs between the Runtime manager and APA manager using Auto Discovery. Remember, we use this auto discovery to link the Runtime manager with the APA manager. Then the clients come and request the access via Any Point, Exchange or Public Portal and get access and hit the API Manager to actually use the APIs. Right? So this is the lifecycle of the API depicted in two different ways APA centric way and the process centric way. So this all involves the complete components offered by the Any Point Platform. Now, let us move on to the next lecture where we see how we can build some strong DevOps foundations to travel through this journey smoothly. All right. Happier earning.

2. DevOps

In this lecture, let us see how to build a strong DevOps foundation for your APA project. As you know, DevOps is very popular these days, right? Why? Because of the success rate the companies are seeing by adopting this DevOps principles. So, what is DevOps? Many of you already may know, but I’m just iterating one more time. Ops are set of principles that are established between the dev and operations teams to smoothly transition the development into the operations so that both the parties leverage the best out of it and keep the things smooth without having much hurdles, right? This adoption of DevOps, which attain agreed principles, brings in the deployment to production by giving more reliability and as much as automation as possible. This is because the defects or failures in business critical API implementations have the potential of affecting the entire application network, right? So adopting such principles will make things more reliable and less leading to the defects or failures. Therefore, strong DevOps capabilities under rigorous development and deployment process are an absolute necessary. OK, now, what are the things that we need to standardize?

So as part of C four E or as the project manager of the application network project, the things that need to be standardized, at least the basic things in the APA project are number one, all RAML definitions and RAML fragments must live in an artifact repository, could be Nexus or could be JFrog. But you can choose, you know, already at any point exchange as well as an artifact repository. And all source code for APA implementations must live in a source code repository. Like the Git is the most popular way because of its distributed version control system. So you can choose GitHub Bitbucket or any other Git based repositories. So every API implementation should have its own Git repo. Again, what you are seeing in front of you is a development under DevOps process that is depicted at a very high level.

And what it describes is like first the developers of an APA implementation implement on the feature branches of the Git develop branch of that APA implementation report. Okay? So that is the Git flow branching model. I am assuming that you already know the branching strategies of Git based repositories. And the second thing is developers implement the mule application and all types of automated tests like unit integration and performance tests and make them pass. For this you use any point studio for the coding and for the testing purpose you can use J unit, Soap UI or JMeter and also the M unit which is a component of the Mule Soft. For build automation. You can choose maven and mule, maven plugin or soap. UI and JMeter Again, for the automation purposes because they also support. Only thing is Soap UI and JMeter are the third party ones, whereas the Mule Maven plugin comes with the Mule Soft and is natively supportive for the mule applications.

Now, once done, developers submit this GitHub pull request from their feature branch into the developer branch. Then a developer from the same team performs a complete code review of the pull request, confirms that, okay, all tests pass and if satisfied, merges the pull request into the development branch of the AP implementations GitHub repository. This triggers the CACD pipeline. The moment the match happens, the CACD Papri will trigger. Okay, so you can again use many CI CD builder tools like bamboo jenkins Hudson There are many others in the market, but here we are just showing Jenkins for the explanation purposes. Okay, so Jenkins is the one we have chosen for this lecture and where once the trigger happens for the CACD pipeline, the mule application is compiled, packaged, and all unit tests that we have done previously are run against an embedded mule runtime. Okay? Then the mule application is deployed to an artifact repository.

Again, you can choose any artifact repository, but again, for this example, we have shown access as the artifact repository. Okay, so when sufficient features have accumulated for the APA implementation, the release manager of the AP implementation cuts a release by tagging, creating a release branch and ultimately merging into the master branch of the APA implementations repository. So, so far it is in dev, right? So it has to be merged all the way from Dev to the release branch and to the master branch. This triggers the CI CD. Pipeline. In Jenkins, the CI pipeline is executed as before, like you saw in the previous steps, leading to the deployment of the mule application into Nexus automatically through a manual trigger or automated way, the CD pipeline is executed. The deployment pipeline, a well defined version of the mule application from the artifact repository, is deployed into a staging environment. For example. Then integration tests and performance tests are run over Https against the API exposed by the API implementation. Upon success, the mule application from the artifact repository is deployed into the production environment.

So the deployment verification subset of the functional integration test is run to verify the success of the deployment. Failure leads to immediate rollback via the execution of the CD pipeline. With the last good version of the AP implementation, it’s a rollback strategy, right? Any project will have this. So any point platform has no direct support for Canary deployments. If you’re not aware of Canary deployments, it’s the practice of initially only directing a small portion of the production traffic to the newly deployed API implementation. Okay? And making sure if things work then only allow the full traffic. So such support is not directly there by the endpoint platform. Today, what here we can represent is just one of the ways or the common way of the CICD setup for the mule. This is not the only way or the only correct way. This is just to give you an idea how it can be set up.

Okay, so the above discussion assumes that previous version of the APA implementation has already been developed and therefore the APA Manager and APA Policy configuration of the APA instance exposed by the API implementation is already in place. So we are not showing the automated promotion of the API instances in the APA Manager and all through CACD resuming that they are already there. Okay? Although the creation of this configuration can be automated using the endpoint platform APIs, you know, right? Every single thing we can do on the AP Manager has the platform APIs.

So there is no limit for every imagination. If you want to even automate the APA instances and APA Policy creations in the platform, you can do so by using the Any Point platform API. But what we have explained in this particular diagram is just a normal APA implementation, how it gets promoted once the code is shaked in from the feature bunch develop branch all the way to the production. Let us move on to the next lecture section. Happy Learning.