Case study 1
Building a serverless text-to-speech web application using AWS Lambda
Problem Statement/ Definition:
We created a text-to-speech web application that converts text into speech, by analysing and processing the text using Natural Language Processing (NLP) and then using Digital Signal Processing (DSP) technology to convert this processed text into synthesized speech representation of the text. Here, we developed a useful text-to-speech synthesizer in the form of a simple application that converts inputted text into synthesized speech and reads out to the user which can then be saved as an .mp3 file. The development of a text to speech synthesizer will be of great help to people with visual impairment and make making through large volume of text easier.
Proposed Solution & Architecture:
we created a basic, serverless application that uses Amazon Polly to convert text to speech. The application has a simple user interface that accepts text in many different languages and then converts it to audio files which you can play from a web browser. For example, you can use the application to read recipes while you are preparing a meal, or news articles or books while you’re driving or riding a bike.
The application’s architecture:
The following diagram shows the application architecture. It uses a serverless approach, which means that we don’t need to work with servers – no provisioning, no patching, no scaling. The Cloud automatically takes care of this, allowing us to focus on our application.
The application provides two methods – one for sending information about a new post, which should be converted into an MP3 file, and one for retrieving information about the post (including a link to the MP3 file stored in an S3 bucket). Both methods are exposed as RESTful web services through Amazon API Gateway. Let’s look at how the interaction works in the application.
Outcomes of Project & Success Metrics:
we created an application that can convert text into speech in dozens of languages and speak that text in even more voices. Although we created the application to convert blog posts into speech, we can use it for many other purposes, such as converting text on websites or adding speech functionality in web applications. And we did it completely serverless. There are no servers to maintain or patch, etc. By default, our application is highly available because AWS Lambda, Amazon API Gateway, Amazon S3, and Amazon DynamoDB use multiple Available Zones. So now what? Use this approach to imagine and build new applications that provide a much better user experience than previously possible.
Case study 2
Our customer, Collinson, a globally renowned business management, was struggling with a public cloud business management solution that could not accurately right-size instances, despite its claims. The company had to rely on manual analysis to right-size instances, which was time consuming and resulted in sub-optimal results. It took the company four months to analyze 17 percent of the environment, leaving the majority of workloads untouched.
After a through workload analysis of few weeks of data utilization using Amazon CloudWatch, it was discovered both CPU performance risks and right-sizing opportunities. Less than 2 percent of the AWS instances were too small and needed additional resources to reduce performance issues. Cost savings of 40% equivalent to £65,000 per month was achieved by scaling down 750 AWS instances and modernizing cloud instance selections for an additional 70 instances. The analysis also discovered additional services that were being used in pockets across the environment that were not in compliance with company policy and were driving up costs.
The company now has confidence that their environment is optimized, and has detailed visibility into what services are being consumed and ongoing optimization of its AWS environment to eliminate risks and waste. They particularly value the support of their Cosmictech Advisor who proactively offers updates and manages the optimization for them.
Case study 3
Aiming to eliminate the time that its IT staff spent maintaining on-site infrastructure, Antibiotice wanted to migrate its applications and data to the cloud. Using Cosmic Tech Migration, the company moved everything to AWS without any hassle. The migration lasted less than a week and went so smoothly that the employees outside of the research department never knew the company’s servers had migrated.
Antibiotice set a goal to shift the applications and data from its 100 servers running in its data centre to AWS by the end of the year. With limited staff, the company’s IT department wanted to spend more time on research and less time managing data and hardware facilities. Antibiotice chose AWS because of its strong reputation. They needed a migration tool that could migrate their data and applications running on VMware architecture, and which would also ensure they met their time constraints for the project.
After several daunting migration tests with another tool, and with a small window in which to migrate and downtime of few hours a month. Using these tools would have taken days of downtime to migrate their applications and data into AWS.
Antibiotice wanted its migration to be handled by a proven enterprise-grade solution that could be deployed quickly, affordably, and without system disruption; they approached Cosmic Tech for solution. And within a few hours of testing, Cosmic Tech had successfully migrated a couple of servers and immediately recognized that they could migrate all of their servers without complication or the limitations experienced with the other tool — and downtime window.
As the migration requires methodically planning to ensure that every bit of data could be replicated before going live in AWS, Cosmic Tech constantly checking the data’s continuous replication status before the planned cutover.
Cosmic Tech successfully replicated Antibiotice’s applications. This process included the initial synchronization of existing server data and the continuous replication of any newly-written server data in real time. It was completed within several days.
Thus, Antibiotice and its administrators were able to test the most up-to-date state of their servers on AWS as many times as needed without any disruption to their source applications. This ensured that when the golden few hours cutover window arrived, they knew exactly what to do, and could complete the cutover in minutes. In the end, Antibiotice was able to spun up the most up-to-date state of their servers in AWS, and shut off their in-house servers.
Case study 4
Mobility of Data
Enterprises are using Docker as their service mobilization engine because it allows movement of services between sites, from on-premise to the cloud, and/or between cloud providers. Docker allows customers to quickly shift workloads based on needs or costs.
However, this creates a data persistence problem that can severely limit continuous integration/continuous development (CI/CD) activities. This is because persistent data is only available locally, which locks organizations into a single vendor or location.
Cosmic Tech makes data mobile, so that data can move anywhere with the application.
Move all your applications to the cloud
Break free from data gravity and migrate 100% of applications to the cloud.
Run your applications anywhere
Shift workloads based on needs or costs very quickly between regions or clouds.
Avoid vendor lock-in
Freely move services between sites, from on premise to the cloud, and/or between cloud providers.
Lower costs through collaboration
Allow developers in different geographies to work together in real-time.