Design and implement Azure PaaS compute and web and mobile services
- Skill 4.1: Design Azure App Service Web Apps
- Skill 4.2: Design Azure App Service API Apps
- Skill 4.3: Develop Azure App Service Logic Apps
- Skill 4.4: Develop Azure App Service Mobile Apps
- Skill 4.5: Implement API Management
- Skill 4.6: Implement Azure Functions and WebJobs
- Skill 4.7: Design and Implement Azure Service Fabric apps
- Skill 4.8: Design and implement third-party Platform as a Service (PaaS)
- Skill 4.9: Design and implement DevOps
- Thought experiment
- Thought experiment answers
- Chapter summary
In this thought experiment, apply what you’ve learned about implementing App Services, Azure Functions, Azure Service Fabric, third-party PaaS, and DevOps to evaluate and determine a recommended set of features to use in a particular solution implementation.
You can find answers to this thought experiment in the next section. The following paragraphs describe the solution and the questions to answer.
You are designing a solution that issues certificates of insurance for end users. You are expecting insurance companies who you partner with to provide this service to their clients, your end user, through your solution. The following describes core components in the solution, and other requirements:
Insurance companies can sign up with your service so that they can call your Policy Sync APIs and send insurance policy data using the X12 EDI standard. Their license with your API determines how much policy data they can upload to your service. This policy data is what supports certificate issuance to the end user owning the policy.
Insurance companies can manage access to those policies through a Policy Management web application that allows them to create users who can later login and request certificates of insurance for their policy data.
End users will, once invited by the insurance company, be able to login to the Certificate Issuance web application to request certificates of insurance on demand for their policies.
When a certificate is requested, a workflow should be kicked off to generate a PDF from the policy data, save the PDF to a secure location from where it can be securely shared, and email a secure link to the PDF to a specified email address.
While this is a new service, it is possible that many 100,000s of requests can be processed by a single insurance company per week so there is potential for large scale growth and the design must be ready to grow with demand.
You are expecting to use a third-party Java-based executable component for PDF generation, alongside the other work, which will be based on ASP.NET Core.
As a startup, you are looking for a solution that allows you to contain costs now, but grow into an architecture that can scale with your business growth.
Consider how you would answer the following questions for this solution:
How would you evaluate the core platform tools and hosting environment that you will use for the web apps and APIs? Consider these aspects:
Cost containment early on with potential for growth.
Manageability with a small team.
Support for polyglot development and third-party application components.
How will you control the onboarding process to use your Policy Sync APIs and subsequent throttling of their use by license?
How will you handle the inbound EDI requests and store those for the partner?
How will you prepare to scale the requests for certificates of insurance based on the potential growth?