• + 1 (844) 772-7527


Healthcare digital transformations using retail digital innovations – Parkar NexGen Platform

974 608 Parkar Consulting & Labs

“Digital transformation is fundamentally about improving patient experience,” says Michael Monteith, CEO of Thoughtwire. It underlines the importance of technologies in transforming not just the business for healthcare companies but also the quality of care and services they provide. Simply put, digital transformation is the integration of digital technology into the way an organization communicates with patients, regulators and other healthcare providers leading to results that are sometimes radical. While processes evolve and experiences improve, they also disrupt the pre-existing and pre-established norms of healthcare. The number one reason many great digital transformation initiatives fail is largely due to the fact that they focus on point problems and not on technology that can provide great experiences. Precisely why, those like Parkar, pay great attention to finer details to ensure that technology is optimized to offer the best experience ever.

Healthcare Digital Transformation Statistics 

Successful digital transformation necessitates a change in culture; one that encourages new methods of working, new ways of thinking and ensures that everyone consciously works towards building effective channels of communication with patients, providers, and regulators. Despite this, a 2018 survey indicates that as opposed to 15 percent of industries that have gone digital, just about 7 percent of healthcare and pharmaceutical companies are going the digital way.

“If you don’t have the IT train on the track, you can’t transform,” says Judy Kirby, CEO of executive search firm Kirby Partners in Heathrow, Fla. “So, you’ve got to do that first, you’ve got to do it well, you’ve got to do it exceptionally.

Healthcare Digital Transformation – Key questions for consideration

You need to look at the bigger picture to understand what you as an organization wishes to achieve and then see how different processes can be aligned in a way that they contribute collectively towards helping you achieve those goals. What you are doing now or how things should be done should help you decide how you want to leverage the technology and not the other way round. Technology should add value and acceleration to ‘how you are doing things now’

Questions you must ask:

  1. How well are we addressing patient concerns and how effectively are we providing patient care and support?
  2. Is there a way to service them in a better, more satisfying manner?
  3. How well are we utilizing employee skills to ensure their role matches their unique skills and interests?
  4. What kind of skills do we want our employees to build or hone?
  5. How can we optimize our processes to ensure the highest quality care?

You could ask yourselves all of the above or engage with a technology platform such as Parkar’s NexGen to ensure that everything is already factored in and solutions provided address these concerns incredibly well.

Prepare for Digital Transformation, as a culture

One thing you must get comfortable with is change. It’s about willing to be uncomfortable to do things that usher in a fresh approach, a fresh perspective and eventually a whole new level of experience.

As Dion Hinchcliffe rightly puts it, “Almost daily, the industry witnesses data points in the tech media that show us that we are currently at a high watermark for technological innovation. In this hyper-competitive yet nearly flat operating environment that organizations face today, the pressure to keep pace and deliver a wider range of digital capabilities has never been greater.”

In order to prepare yourself to offer great customer experience, you must:

  • Relook at the organization’s current state of readiness and the willingness of teams to change and adapt. Frontline staff, clinicians, management teams and all caregivers should be willing to change for the better to deliver beyond expectations.
  • Encourage a culture of change and continuous improvement by challenging the way things are in the present and do better.
  • Mistakes should be perceived as stepping stones and lessons should be learned. Failure should therefore not be punished. It should be looked upon as a by-product of experimentation that will help you pinpoint the things you should not do.

Create a Plan for Healthcare Digital Transformation

Once you do your homework and are done with the initial assessment of the preparedness of the organization, you need to look at how the community perceives it. You need to understand the expectations of your patients to serve them better.

Once you have answers to all these questions, you can then devise a plan.

Simply ask for feedback, especially from employees and patients. Only then would you be able to keep your initiatives on course and tide over roadblocks if any. Feedback must be in real-time to understand exactly where modifications are required.

No matter how good a plan is, it will succeed only when everyone concerned is on board.

Now that you have created a culture of change, you need to move on to embrace retail innovations that will drive your goals further. An old research by Pew had quite set the tone for better breakthroughs and initiatives in digital transformation in healthcare. According to the research, 1 in 3 American adults have gone online to understand a medical condition.

It further stated that:

  • 59% of US adults go online for health information in the past year
  • 35% are online diagnosers who have gone online looking for a medical condition they or someone they know may have
  • 53% discuss with a clinician about things they learned online
  • 41% got their condition confirmed via a clinician

Meeting patients where they are: Learning from Retail Digital Innovation

The healthcare industry is fast moving away from a typical monolith hospital setting to offer greater convenience to patients. Research by the Advisory Board – healthcare consulting firm suggested that from 2006 to 2016, inpatient hospital visits had gone down to just 6% while outpatient visits had surged to a good 20.4%, and predicted a further drop of 3.7% in inpatient visits and a rise of 58.% in outpatient visits in the next ten years. Needless to say, healthcare facilities unanimously are working towards increasing their outpatient market share.

The focus was largely on offering:

  • A more convenient location
  • Relaxing environment
  • Consistent branding

These three factors now form the core of retail.

The following are retail innovation trends that are now defining customer experiences in the healthcare segment.

Fig: Retail Innovation trends that are now defining customer experiences in the Healthcare Segment


The number of telehealth patients rose from 1 million in 2015 to 7 million by 2018. Telehealth technology is taking quality healthcare to the most remote locations thereby bridging the gap between good healthcare and the patients seeking it. So if you cannot afford to actually go to a different city or country for the best cancer treatment, telemedicine enables the specialist to connect with your doctor digitally to give you the same care and guidance irrespective of geographical constraints.

Artificial intelligence

Artificial intelligence has enabled faster treatment. AI and deep learning have made CAT scans up to 150 times faster as compared to human professionals with an ability to detect acute neurological events in just 1.2 seconds. What you get is precise on-the-spot answers without waiting it out in concern and confusion. Artificial intelligence also enables faster trials and better medicines thanks to its ability to determine the most effective pharmaceutical compositions.


Those who have changed doctors in the middle of the treatment would know how frustrating it is to keep a tab on all developments and maintain records. Blockchain, however, ensures seamless data transfer offering complete medical history to doctors and specialists to treat in the best possible manner. Also, it eliminates data security issues and helps hospitals and insurance companies save big on data protection.


Together, AR and VR can help Alzheimer’s and dementia patients retrieve memory by taking them to a time or place in memory via a sound or experience from the past that was important to them. This is how digital transformation is altering the healthcare landscape in the most rewarding manner. Imagine, taking people back to their childhood or early years and helping them revisit experiences to think better and remember what they had lost touch with.

Digital twin

When healthcare providers want to experiment with ‘what if’, digital twin allows them to recreate the physical environment to test the impact of potential change by experimenting on a virtual version of the person or device. Digital twins now offer greater insights and are helping improve healthcare procedures in a big way.

Parkar NexGen Platform in the healthcare scenario

Always being at the forefront of things, Parkar uses a recommendation engine to ensure care that is personal, proactive and prompt. Remember how fast Amazon comes up with recommendations when it understands you and your requirements? Our recommendation engine relies on big data and predictive analytics to help patients with solutions and diagnoses on the basis of their case history. While doing so, we ensure that our recommendations are approved by the best healthcare specialists.

We’ve built our recommendation system using prediction and recommendation with the help of a dataset of patients’ case history, expert rules, and social media data to train and build a model that is able to predict and recommend disease risk, diagnosis and alternative medicines. All the predictions and treatment recommendations are approved by physicians.

Those who have used our platform have experienced:

  • Fast, reliable results
  • High conversion rate as compared to non-personalized products
  • Greater patient satisfaction
  • Improved personalization for the digital channels

Fig: NexGen Platform Value experienced by customers in healthcare organization

Parkar NexGen Platform – The Digital Transformation Accelerator

Digital transformation is inevitable to help provide the differentiated and much-needed customer experience.

While the right culture, service quality, organization skill is critical to successful transformation journey, technology is the enabler.

Retail digital transformation has been driven by innovations around technology like Artificial Intelligence, recommendation engine, blockchain, AR&VR, etc.

The healthcare industry can take cue from the retail innovation and apply them to healthcare to help give good patient care experience.

Parkar is all about innovation and improvisation. Through its NexGen platform, it endeavors to offer better solutions and results to its customers. No matter where you are, all you need is a Parkar edge to succeed.

Production-ready Microservices simplified with Parkar NexGen Platform

974 608 Parkar Consulting & Labs

A lot of organizations end-up facing scalability limitations and development velocity comes to a screeching halt. This is the time when they adopt microservice architecture. It is also often the most natural progression for evolving software applications.

In our previous blogs, we defined a microservice architecture and what goes into its making. The key aspect, however, is to ensure that microservices are production ready.

Let’s delve deeper into what production-ready microservices are all about.

True spirit of microservices  adoption

Despite the fact that software systems often embrace microservices as the next major step towards evolution, it is important to remember that they were not built keeping a microservice architecture in mind.

This, in turn, causes problems and hiccups – both organizational and technical in nature.

So what happens at the organizational end?

Well, what you get is isolated teams working on their own set of microservices with zero lack of awareness of what the other teams are up to. Not to mention, the lack of trust between teams who have no idea how other microservices that support their own service are as reliable, stable and scalable.

Having a dedicated staff for operations management in microservice ecosystems will not always be possible. During such times, developers need to step forward and take charge of operational duties for their microservices. It goes without saying that most would be unfamiliar with the tasks and may also be reluctant to do something they have no idea about. As such, organizations need to initiate a lot of cross-team collaboration to ease out things at their end.

Likewise, there are challenges on the technical side too.

There would be compatibility issues between microservices. This would be largely because their functionality was never really defined when the decision was taken to split the monolith into microservices. This may cause a blurring of boundaries and overall communication with respect to collaboration and understanding of each other’s roles.

In addition, for a thriving microservice architecture, it is important that the microservices are extremely refined. This is an important consideration for organizations that are used to running monolith applications and often tend to overlook its significance.

Transitioning to production ready microservices

Developers need to hone their skills to handle operational tasks well. While it is easy to split dev and ops duties in a typical monolith environment and manage both via separate teams, microservice architecture does not really give you that luxury. And in a way, it’s better that way.

There will be a multitude of microservices within the architecture and dual-staffing these for developers and ops engineers do not really serve the purpose from an organizational perspective. Not to forget the fact that devs move so swiftly in a microservice architecture that having operations engineers to run the services does not make any sense whatsoever. The devs take charge and drive the microservice architecture, they being the ones who know how to run it best.

Also, the organization needs to work hard towards building an application platform infrastructure that’s stable, reliable and sophisticated.

The cost factor while transitioning from Legacy to Microservices Architecture

It becomes necessary for organizations to justify the overhead while transitioning from legacy to microservice architecture. Having said that, companies should do the groundwork mentioned above to ensure they are good candidates for microservices.

In situations where the application is complex but the functionalities are well-defined with very clear boundaries, microservices work incredibly well.

There are situations however wherein an application reaches a point where scalability becomes an issue. These limitations often pose a serious threat to performance and stability, hampering developer velocity in a big way. In such a scenario, which is far too common, it makes sense to bring in microservices and justify the cost without which it would be impossible to scale the application.

Deploying production-ready microservices

You can simply wrap a microservice with all dependencies into a container and deploy it as needed. So you could deploy it on-prem, cloud or any operating system as per the requirement.

Having packed all the runtime dependencies together, you don’t have to worry about runtime environment factors that could lead to costly deployment failures that may occur during deployment in different environments.

This reduces the operational cost to a great extent and instills greater stability. The good thing is that you can repeat deployments of multiple microservices and keep a tab on all of them with the right microservices platform.

Parameters determining production-readiness

There are certain parameters in place or standards that organizations adhere to, in order to ensure the successful adoption of production-ready microservices. Production-ready microservices are often well-equipped to handle any catastrophe and are reliable, scalable, fault-tolerant and stable.

Fig: Parameters determining Production Readiness of  Microservice(s)


Let’s look at the most important ones:

  1. Reliability – Organizations need to develop and deploy microservices that can safeguard systems against dependency failures.
  2. Performance – The critical components must be studied and deployed to ensure greater efficiency and scalability.
  3. Fault tolerance – It is impossible to prepare microservices to fight catastrophes unless you push them to fail in real-time.
  4. Monitoring – You need to monitor and log, and study key metrics. On-call procedures and alerts should also be looked into.
  5. Documentation – Mitigate trade-offs like organizational sprawl and technical debt that are often part and parcel of microservice adoption.

 Why Parkar’s NexGen platform?

Often, the frustration and confusion arises from a lack of clarity around microservice architecture and calls for a better understanding of what entails the adoption of microservice architecture. If you think merely putting your application in Docker containers is equal to having microservice architecture, nothing can be further from the truth.

Typically, the microservice architecture can be split into four layers that comprise hardware, communication, application platform, and microservices.

Although the ideal scenario necessitates concerned teams to understand them well, the functionality of Parkar’s NexGen platform makes everything a lot easier.

Using our NexGen platform, from discovery to roadmap to delivery, it’s a 24-week process of application transformation.

NexGen process and technology involves automation, containerization, and microservices to truly transform our client’s journey from legacy to serverless. They get greater agility and flexibility as the Parkar NexGen Platform significantly reduces the migration and development efforts.

Fig: Why Parkar NexGen Platform?

A robust microservice architecture factor in all the above concerns in development as well as operational contexts. So, the development teams get clarity at design time while the operations teams build and support the necessary infrastructure to gather data reported by applications and platforms.

When an application is built with the Parkar NexGen Platform, it is quick to spot anomalies and prevent failures way before they occur.

Broad benefits of Parkar NexGen Platform

There is a reason why our customers trust us. Everything about our platform is conceptualized keeping the constant need for speed in mind.


These are the things you can expect from our innovative NexGen Platform:

Greater speed and productivity – Thanks to the platform, different teams can work simultaneously on different projects without having to wait for others to complete a task. Despite excellent collaboration, there is no dependency to hamper work speed or productivity.

Excellent scalability – Each microservice can be written with a different technology which ensures that the task of choosing the right stack for specific needs is uncomplicated. Even decoupled services written in diverse programming languages manage to exist in harmony along with others. So when you decide to scale your solution, you can simply add components or services with ease.

More independence – Development of a massive monolith can never be simple unless you have the capabilities of a platform such as Parkar NexGen. It allows teams to work autonomously around the globe or in tandem with extended teams giving them the independence necessary to make technical decisions quickly within a group.

Unmatched simplicity – Considering that each microservice happens to be a separate chunk of code, it is easier to manage the code. Services can be built, deployed, rebuilt and re-deployed as required and managed independently using the NexGen Platform.

Enhanced capabilities – Services can be easily adapted to be used in multiple contexts, which means you can use the same service in different business processes or across diverse business channels as required. If you decide to assign services to team members, you can easily build a smart, cross-functional team that works together to ensure zero friction and exemplary team spirit.

High security – Every time you need to access a microservice that’s outside of the organization’s network, you are required to open a network port that in turns causes security concerns. This is because when you have several opened ports, you are actually increasing the attack surface. This necessitates a reverse proxy or an API gateway layer so that microservices are guarded against exposure to public networks. NexGen Platform ensures secured data access through enterprise API for third-party data interoperability across the architecture and systems.

The platform offers a robust ecosystem to ensure better deployment and management of microservices. When used properly, it can support several use cases. Production-ready microservices come in handy for organizations that have been used to using different languages, libraries, frameworks, and data storage technologies that can be extremely tedious and time-consuming.

Summing up: Robust Ecosystem to Manage Microservices

Production-ready microservices may be just what you need if you wish to build a robust ecosystem to manage microservices. They give teams the freedom to use technology stacks of their choice and the power to operate independently while ensuring peaceful co-existence. If you wish to know the trade-offs of having production-ready microservices, call us today.

Allow us to assess your environment and we will help you choose solutions and strategies that are right for you.

Revolutionize Your Microservices Application Monitoring With Parkar NexGen Platform

974 608 Parkar Consulting & Labs

Our previous blog addressed SRE and its nitty-gritty and how Google influences our approach towards it. At Parkar, it’s all about helping you get there faster no matter how nuanced your needs are and which stage of adoption you are at while looking for services. It’s all about the need for speed. Not surprising then, this blog is dedicated to microservices and the critical aspect of monitoring them.  In this blog, we will talk about microservices and the critical aspect of monitoring them.

Things were different when you used the traditional monolith system that had different points of failure and dependencies when deployed as a single executable or library. But when it comes to monitoring microservices applications, it is important to get a fresh perspective. Microservices based applications have unique, intensive requirements necessitating all concerned to correlate data from various services. It has very specific monitoring requirements too.

Microservices monitoring – Whys & Hows

Before we delve deeper, we need to have answers to the following questions:

  • Why should systems be monitored and how are things different when monitoring the microservices architecture?
  • What kind of data is required?
  • What are the tools you should be using for publishing, collating and storing data?

What are Microservices

We’ve already explained in detail what microservices is all about in our earlier blogs. It is an architectural style that structures an application as a collection of services that are easy to maintain and test. These services are loosely coupled, independently deployable, and meticulously organized keeping business capabilities in mind.

Often, these are owned by a small team that relies on the microservice architecture to ensure rapid, frequent and reliable delivery of large, complex applications while evolving the organization’s technology stack.

There are potholes to avoid on your road to successful implementation and challenges and strategies too that we’ve covered in detail in our previous blogs.

Moving on, we now tell you how to assess and monitor microservices.

The monolith architecture pattern has worked well for many organizations for several applications, though its limitations are hard to overlook.

Many larger organizations with more complex applications are migrating to the microservice architecture pattern. If you have already migrated and built an application with the microservice architecture, we’ll tell you the ways and means to monitor it and reduce architectural and organizational risk.

Microservices Application Monitoring

For starters, let’s accept no one likes to fail. Complex systems, even monoliths, can operate in a degraded state causing a huge impact on performance and eventually leading to failures.

Monitoring ensures that operators are alert and well-equipped to manage systems as they hit the degraded state way before total failure occurs. As you are aware, there is a Service Level Agreement in place when such services are offered. But the only way to know if it was being honored or not is through effective monitoring.

Monitoring will also render invaluable data that can be employed effectively to enhance service performance.

There will be patterns in system failures that would otherwise go unnoticed. Often times, there is a correlation between events.

Imagine getting information that confirms that most of the time, total system failures occur within an hour of a new deployment.

This kind of information is critical and would alert operators to pay greater attention to the deployment process. This is where application performance monitoring or APM comes into play and is fast burgeoning into a market of its own.

The role of APM is so dominant today that Gartner even publishes a Magic Quadrant report for APM suites. According to a survey by Gartner, 61% of respondents identified APM as important or critical out of which 46% cited end-user experience monitoring as the most critical dimension of APM. It is important however that you are not swayed by everything that’s promised and take the time to critically review solutions that are being offered and look into their ability to adapt to more complex systems and environments.

At Parkar, we raise the benchmarks for end-user experience monitoring. Our focus has been to deliver greater functionality and reliability and our NexGen Platform ensures just that. We offer excellent alerting features and data that can be used effectively by the development and operation teams to shift and filter out all but critically important events. These alerts, in turn, can be escalated via dashboards, emails and other means.

The architecture which encompasses monitoring

As opposed to monoliths that are usually deployed as a single executable or binary library, microservices applications are often deployed as a family of independent services wherein each service is assigned a special function. These services are also expected to communicate with other services to ensure that a particular task or unit of work is carried out in a symbiotic manner.

Through a series of microservices, complex workflows are orchestrated and each service communicates with dependent resources such as a disk or a database or other services as required. This means every interaction is likely to be a potential point of failure that can have a huge impact on the entire system. The only way to prevent systemic degradation or failures is to detect issues early on and raise an alarm.

A robust microservice architecture factor in all the above concerns in development as well as operational contexts. So the development teams get clarity at design time while the operations teams build and support the necessary infrastructure to gather data reported by applications and platforms.

For the short term, the data is used for emergency scenarios like sending out alerts, while for long-term it comes in handy for data mining and analytics to look for patterns. Patterns offer useful insights when it comes to the analysis of common reasons for failures.

Microservices Application Monitoring Metrics to get insights

Application metrics: This applies to the application we are using.

Let’s take an example of a healthcare application, say Patient Registration application. The application accepts user registrations and you would want to know how many registrations were successfully completed in a specific amount of time. This kind of information is necessary for development teams and the organization as a whole to understand how the system functions.

To elaborate this further, let’s take an example where the system usually completes 1000 registrations in an hour and suddenly they drop to just 300 in the last couple of hours.

You know there’s a major cause of concern and the system needs to be immediately investigated for anomalies.

Platform metrics:  These metrics are just what you need to tighten your grip on the infrastructure.

Average response time, average execution time, the number of requests received per minute, etc. are good examples of platform metrics.

Together, they typically offer a dashboard that throws light on low-level system performance and behavior. They alert you to degraded performances that impact overall throughput or lead to a system-wide failure.

Parkar NexGen platform is quick to spot anomalies and prevent failures way before they occur.

Operational Metrics: There will be operational issues that are often disruptive. A classic case in point – new deployments. The correlation between new code deployments and system failures is well known. It is a good idea to record such instances including scaling events, configuration updates, and other operational changes that are crucial and important candidates for monitoring to ensure good system behavior.

A lot of customers use the Parkar NexGen platform to manage and monitor their application deployment. This ensures that there is no loose end and the inbuilt monitoring as part of the NexGen platform takes care of operational issues.

Parkar NexGen Platform and Monitoring

The constant need for speed has given Parkar the edge and motivation to come up with a solution that is revolutionary in every way. As environments and architectures continue to evolve and become more complex, monitoring too is becoming equally complex and critical.

Not surprising then, this need has caused a ripple effect within software management, including monitoring systems. What we offer is a platform that helps you tide over monitoring challenges and level up your business.

Parkar NexGen Platform critically monitors, with the help of Nagios, Datadog:

  • System
  • Infrastructure
  • Networks
  • Containers
  • Applications
  • Databases
  • Webservers
  • Service performance
  • Multi-location services
  • Cloud-Scale monitoring
  • Log consolidation, event correlation
  • APIs

It is important to align your monitoring with the organizational structure. To facilitate smart and effective monitoring, our NexGen Platform ensures that monitoring is easily configurable, non-intrusive and highly scalable.



Fig: Parkar NexGen Platform Benefits

NexGen Platform benefits:

  • Integrates legacy system and marketplace systems to accelerate your digital transformation journey
  • Reduces app release time from months to days
  • Ensures shorter build times for rapid deployment of new updates and version releases
  • Provides secured data access through enterprise API for third-party data interoperability between legacy and modern systems
  • Offers web service mesh for easy connection with third party wearables and customer platforms
  • Facilitates scalable governance of multiple applications with enterprise-grade protection and support
  • Provides visibility across all the data streams and usage

In closing

The monitoring of microservices is critical. Parkar with its highly effective NexGen Platform is changing the way organizations are addressing their monitoring needs. It offers amazing capabilities to users helping them move with agility in the right direction. It is changing business dynamics not only from microservices perspective but also with its approach towards AIOps. You can experience its benefits too.

Let us talk to assess your environment and we will help you with insights and capabilities to make better business decisions

The Microservices Vs SOA Vs API Mystery Revealed

974 608 Parkar Consulting & Labs

In software development, there has been a major drift in the way organizations invest, deploying an architecture-oriented approach. It all started with SOA and then transfigured into something that we call as Microservices. Added to them was another concept, designated as API.

For the past few years, SOA and microservices have remained a topic for discussion. With time, organizations feel the need to transform their workflow and adopt microservice for their software systems.

To start with, we define each of them separately and figure out where the difference lies.

Fig: Different Application architectures 

APIs or Application Programming Interfaces

APIs or application programming interface is a lightweight protocol used by developers for initiating communication between client and server. APIs are all about adding transparency while allowing multiple products or services to interact with each other.

It becomes easy to upgrade an existing infrastructure by adding distinct applications with the help of APIs. APIs extend support when organizations need to migrate to the cloud or shift their existing applications to the cloud. Given the ease rendered, APIs help enterprises collaborate with the teams of IT for integration with cloud-native applications. And that’s where the concept of microservices comes into the picture.

The majority of the cloud-driven operations are based on microservices and they use APIs to connect to the same.

As per WSO2, APIs now account for 25% of internet traffic.

Developers find APIs, one of the most convenient ways, when they seek to connect the organizational ecosystem with the cloud-driven app.

Salient Features of APIs:

  • Outline protocols that determine the manner in which two parties connect.
  • Allow developers to enhance the productivity of developed applications by integrating third-party services
  • Allow microservices to communicate with others
  • In the connected world of today, information is being shared via APIs to external and internal teams, security is a top concern. APIs provide adherence to security standards and safety needs

SOA or Service Oriented Architecture

SOA is an enterprise-oriented form of architecture. It is regarded as one form of software development where different modules of the applications render services to another taking the help of network-specific communication protocols. Now, the communication could be anything from passing a single argument to requesting a piece of information or collaborating for multiple services.

Primarily, SOA emphasizes on the development of individual functions as carried out by each component in a standalone environment. It could be anything from validating a payment or allowing third-party sign-in.


Fig : SOA Architecture Elements


It is evident that service-oriented architecture is not about modularizing an application but connecting or combining different services to build an app. In simple terms, service-oriented architecture is more about rendering a service, disregarding the fact, how. You can also consider them to be the simplified version of microservices. They are loosely coupled and use enterprise bus messaging protocol to initiate communication between two services.

As per Gartner “SOA reduces redundancy and increases usability, maintainability, and value. This produces interoperable, modular systems that are easier to use and maintain. SOA creates simpler and faster systems that increase agility and reduce total cost of ownership (TCO).”

A well-crafted SOA increases agility over time.

Salient features of SOA:

  • SOA is coarsely grained form of a monolithic application
  • SOA uses the IP network to communicate and connect with distinct services
  • SOA supports multiple message protocol like AMQP, MSMQ and SOAP


Microservices, as a generic term, is kind of a software development methodology that focuses on developing modules or smaller chunks of an application. Later, these can be deployed independently within any application, and communicate with the help of the APIs. Unlike, service-oriented architecture, one that uses the enterprise-level messaging protocol, particularly, the IP, microservices induce APIs to connect with distinct modules.



To put it this way, microservices allow developers to create smaller services and then combine each to cohesively work as a single application. Where developing the entire application as a single standalone concept appears a lot fussy, microservices eases the task of the developer enabling them to work on separate modules independently and then integrate all the services to form the app.

Each module or the service built is capable of running its own process. These services can be integrated with any other service making use of lightweight protocols, called API. It is these APIs that enable the two microservices to communicate with each other.

For instance, consider you have a Healthcare Portal and you want to add an authentication page. What you can do is create a distinct application that is solely dedicated to do authentication and then integrate the same within the existing infrastructure using any kind of communication protocol.

Fig : Microservices Architecture


Salient features of Microservices:

  • Microservices eliminate the concept of centralized governance
  • Allow developers to build smaller modules that can run independently.
  • Allow teams to work separately on distinct services and then recombine them as and when needed.
  • Microservices are granulated SOA.
  • Microservices are, generally, deployed in containers

When we look at the three together, we know that APIs are protocols or standards used by developers to initiate communication between two services or applications.


Fig: APIs glueing : Monolithic Applications, SOA designed modular apps and microservices

Major Differences – SOA Vs Microservices

  • SOA is service driven and focuses on maximizing service reusability. On the contrary, microservices follow a decentralized approach, where the entire application is decoupled in separate components and each component can be used separately in a standalone environment.
  • SOA makes use of the enterprise bus messaging protocol to promote communication between the two intervening parties, whereas microservices, remaining a step ahead, use APIs to communicate between two components.
  • SOA aims to enhance the reusability of an application, following the share as much as a possible approach. While reusability is possible for microservies too, it promotes decoupling components to build distinct applications, following a share as little as a possible approach.
  • For SOA, any change or modification in the application requires updating the entire monolith. But for organizations that deploy microservices, a new feature calls for new service integration.
  • SOA makes use of multiple messaging protocols whereas microservices are more inclined towards the security aspect and hence, embed lightweight protocols such as APIs, https, etc.
  • Services that share the same data storage are vulnerable to data leaks. Microservices, on the other hand, deploy independent databases for each application, maintaining the integrity of the information stored. In addition, this also helps with performance and scale.
  • SOA promotes sharing multiple components which leads to the creation of data dependency. Microservices couple each component into a single unit, which is independent. This quickens or enhances the speed of the system built using microservices. This, of course, is a big drawback for organizations investing in SOA. In turn, microservices have better time to market advantages.
  • Microservices are smaller components and each is designed to cover up a single purpose. An SOA is bigger in size and the components involved cater to more than one function. Microservices being smaller components makes it  more maintainable.

Summing it up

It is evident that microservices are the finest form of SOA and use APIs to communicate with each other. It would not be wrong to state that an API is a crucial element of microservices. It is only with the help of APIs that two microservices communicate with each other to build the final application.

In short microservices focus on what do you want to solve? Employing the microservices kind of architecture, you would need the right set of strategies as decomposing the application into a microservice-based application isn’t easy, let alone defining it.

The choice of architecture is better suited to the requirements of the project. For applications that mandate complex elements with varied structural components, SOA serves the purpose. On the other hand, for instances where developers seek a better hold at their development process, segmenting applications into smaller chunks, microservices lead the charge.

Each has its own set of features and custom-fit to map a particular requirement. And so it is the application that determines which architecture would benefit the development process.

How Google Is Changing the way we Approach SRE

974 608 Parkar Consulting & Labs

Software developers find themselves chasing bugs and putting out production fires a bit too often with new codes and updates coming up all the time. Any web application that enjoys decent traffic will often end up with challenges pertaining to overseeing deployments, monitoring performance and reviewing error logs.

While the development teams want to get things moving really fast, the operation teams are always cautious fearing things might blow up in production. This is where site reliability engineering or SRE comes into play.

SRE empowers software developers to own up the ongoing daily operation of the application in the production phase. In that sense, it eliminates considerable load pertaining to application monitoring off the shoulders of operations teams.

Says Niall Murphy, “SRE is what happens when you ask a software engineer to design an operations function.”

Endowed with a deep understanding of the application, the code and how it’s configured, site reliability engineers know exactly how it runs and scales.

SRE at Google

At Google, SRE is an integral aspect of engineering and perceived as something that happens when a software engineer is asked to solve an operational problem. As such, it considers SRE as a mindset; a set of metrics, practices, and means to ensure systems reliability.

Often times, there is no clarity when it comes to pinpointing exactly what successful SRE implementation is. Google has it all- from workbooks and tips to non-exhaustive checklists that can be used as per the needs and priorities of team members.

SRE is not an exact science, which means challenges will vary and continue to crop up along the way. In that sense, SRE is an ongoing journey perfected with experience and sincere efforts.

Google aims to keep critical systems up and running despite natural calamities, bandwidth outages, and configuration errors. Google has its own platforms to manage, maintain and monitor them, and also repair, extend or scale code to keep them working.

For the same reason, Google’s SRE teams comprise people from both systems and software backgrounds. This informed mix has been helping Google address mammoth tasks such as developing large systems ranging from planet-spanning databases to near real-time scalable data warehousing.

Managing a range of systems and catering to a user population measured in billions, Google drives reliability and performance by mastering the full depth of the stack.

Automating jobs is key to SRE

Google has always been working diligently on determining the amount of time a team member is allowed to spend on toil.

While some take this limit as a cap, Google encourages its customers to look at it as a guarantee and a means to curating an engineering-based approach to problems instead of toiling at them aimlessly and laboriously.

In a typical Google environment, you enjoy reduced mean time to repair (MTTR) and greater agility for developers since early detection of problems means lesser time and challenges in fixing them. Late problem recovery is not so much of a problem anymore with Google enabled SRE.

SRE the Google way

Google’s SRE team is a mix of academic and intellectual backgrounds. While doing work that has been historically done by the operations team, the SREs have software expertise with a predisposition and ability to design and implement automation to replace human labor.

While doing so, they are focused on their core- engineering. Without engineering, it is impossible to keep pace with the growing workload. A conventional ops-focused group then begins to scale linearly in tandem with service size.

Google places a 50% cap on the average ‘ops’ work including on-call, tickets, manual tasks, etc., for all SREs to ensure efficient management of workload and also that the SRE team has enough time on hand to make the service stable and operable.

The SRE team is expected to have very little work on the operational front and should engage actively in development tasks. The idea is a move towards an ‘automatic’ not just an automated environment where systems will run and repair themselves.

Google expects SRE teams to utilize the remaining 50% of the time on development. For this, the way SRE time is spent is closely monitored. This could require shifting some of the work back to the development team or adding more staff without assigning the team additional operational responsibilities in a way that there is a balance between development and ops tasks and the SREs have greater bandwidth to engage in autonomous engineering.

This approach has many advantages. These include:

  • Bridging the gap between ops and development teams
  • Constant monitoring and analysis of application performance
  • Effective planning and maintenance of operational runbooks
  • Meaningful contribution towards overall product roadmap
  • Manage on-call and emergency support
  • Ensure good logging and diagnostics for software

Our approach to SRE

While Google continues to offer unmatched capabilities with SRE, we assume the responsibility of offering viable, customizable SRE to our customers keeping the signature benefits intact. We offer the best in SRE which is backed by our NexGen platform.

The SRE team at Parkar is responsible for latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning.

We ensure a durable focus on engineering, enabling to move fast without breaking any SLO.

At Parkar the SRE team has two goals.

  • A short term goal to fulfill the product’s business needs by providing an operationally stable system that is available and scales with demand, with an eye on maintainability, and
  • A long term goal to optimize service operations to a level where ongoing human work is no longer needed, so the SRE team, can move on to work on the next high-value engagement.

Proactive planning and coordinated execution ensure that the SRE team meets expectations and product goals while optimizing operations and reducing operational costs.

The planning is done at two connected levels,

  1. With developer leadership, priorities are set for products and services and yearly roadmaps are published.
  2. The roadmaps are reviewed and updated on a regular basis and quarterly or otherwise goals are derived that line up with the roadmap.

Some of our key SRE aspects include:

  • Reliability – Maintaining a high level of network and application availability
  • Monitoring—Implementing performance metrics and establishing benchmarks for better monitoring
  • Alerting—Promptly identifying issues and ensuring that there is a closed loop support process in place to solve them
  • Infrastructure—Understanding cloud and physical infrastructure scalability and limitations
  • Application Engineering—Understanding application requirements including testing and readiness needs
  • Debugging—Taking into account specifics pertaining to systems, log files, code, use case and troubleshooting to debug as required
  • Security—Understanding common security issues, as well as tracking and addressing vulnerabilities, to ensure systems are properly secured
  • Documentation – Prescribing solutions, production support playbooks, etc. keeping in line with best practices
  • Best Practice Training – Promoting and evangelizing SRE best practices through production readiness reviews, blameless post-mortems, technical talks, and tooling

Parkar SRE team enabled a leading retail organization in the US to achieve efficiency in monitoring and alerts enabling the organization to attain a very high site availability and vastly improved performance with a reduction in manual efforts for managing the overall site.

The early wins are

    1. Achieved 90% fast identification/removal rate of Production Issues.
    2. Achieved 99.99% High Reliability and availability.
    3. Achieved 85% improved and efficient Monitoring and alerts.

SRE onboarding

While there are a few basic things to consider, SRE onboarding rules are not written in stone. They vary from one organization to another. Organizations need to understand how they can benefit from embracing SRE. Identifying implementation and operational deficiencies can go a long way in the effective adoption of SRE. Once the decision to embrace SRE is made, it becomes necessary to identify bug fixes, process changes and determine the required service behavior before onboarding the service.

Let us talk to assess your environment and discover a whole new world of possibilities.

How to Create Your Top AIOps Tools Strategy

974 608 Parkar Consulting & Labs

Two of Australia’s largest supermarket chains had to close their stores last year due to technical issues they suffered nationwide. This resulted in a huge loss of revenue, not to mention the high level of frustration faced by customers. It could have however been avoided.

The truth is that IT teams are dealing with a huge amount of data using tools and techniques that are often causing delays in identifying and resolving issues. What they need is a robust AIOps strategy. When leveraged well, AIOps will have a transformative effect on IT.

As Senior Director Analyst Padraig Byrne at Gartner rightly points out, “IT operations are challenged by the rapid growth in data volumes generated by IT infrastructure and applications that must be captured, analysed and acted on. Coupled with the reality that IT operations teams often work in disconnected silos, this makes it challenging to ensure that the most urgent incident at any given time is being addressed.”

The immediate need is to prevent, identify and resolve high-severity outages and other related problems that pose challenges for the Operations teams.

The answer? Artificial Intelligence for IT operations (AIOps). What they need then is a roadmap that’s robust and effective. Here’s how we can create the perfect AIOps tools strategy.

Traditional tools and AIOps

According to Gartner, the exclusive use of AIOps to monitor applications and infrastructure in large enterprises will rise to 30% in 2023 as compared to 5% in 2018. In our previous blog, we had discussed the many components of AIOps.

It’s time we understood how we can take the AIOps plan forward. An emerging trend as identified by Gartner suggests that the traditional tools and processes are not suited for dealing with the challenges faced by modern digital enterprises due to the humungous amounts of data and agility.

Gartner believes that organizations need a big data platform that allows the merging and coexistence of IT Service Management (ITSM), IT Operations Management (ITOM), and IT Automation at the data layer.

The platform should support real-time analytics that is managed by machine learning that processes and supports supervised as well as unsupervised data and also has answers to deep historical queries.

Tools in IT silos will remain sovereign, which means, Service Management will still handle incidents, requests, etc. while Performance Management will manage metrics, events, logs, etc. but the data will be connected and analysed in a way that enterprises would be able to make faster decisions while speeding up process and task automation.

The goal of AIOps tools strategy

The ultimate goal for having an AIOps tool strategy is to ensure that the data flows freely from multiple IT data sources into the platform. And then it is analysed and processed, automated workflows are triggered. And the entire system works in a way that it adapts and responds to the changing data volumes. The response should be automatically adjusted as per the data and its sensitivity and concerned administrators should be duly informed.

Use cases must be identified early on. The focus should be on questioning the ‘why’ of desired outcomes, prioritizing use cases, and identifying the gaps between capabilities, tools, skills, and processes.

With time, technologies will change, priorities will shift and new use cases will keep coming up, and accordingly, your desired outcomes will change too. Your AIOps tools strategy, therefore, should be able to address these challenges and open up a whole new world of possibilities.

Assess your data streaming capabilities to help with AIOps

The whole crux or the intent of the strategy would be to ensure the free flow of data from disparate tools into the big data platform. You, therefore, need to assess the ease and frequency with which data flows so that you can receive and send data in real-time.

Not all IT monitoring and service desk tools support outbound data streaming. While they may support programmatic interaction in the latest versions using REST API, they may not support streaming in the case of traditional relational databases like Oracle or SQL even if they have a programmatic interface. Due to this lack of support, the performance impact will not be as desired. You need to have clear answers to questions like:

  • How and what kind of data do I get from existing tools?
  • How often can I use it?
  • Will I be able to do so programmatically?

Once you have pertinent answers, you will be in a position to tweak your data consolidation strategy and replace your IT tools for effective data streaming in real-time. Assessment of data streaming capabilities, therefore, should be treated as a high-priority task when you decide to develop an AIOps tools strategy.

Establish mutually agreeable data sharing practices for better management

It is important that the IT Operations team and the IT Service Management team come together to review the data jointly. For the same, it is crucial to have clearly defined roles and responsibilities.

While they don’t need to analyse the entire volume of data, they would still require assessing of data that tells them what’s happening in their environment, what actions need to be taken and accordingly make decisions that are tracked for effectiveness.

Teams should agree on the following:

  • Deciding what data is required
  • Where it can be stored
  • Create joint access for sharing and review

With DevOps teams using Jira to log defects and enhancements, it has become even more important for enterprises to identify challenges and work unanimously to arrive at a plan to collate and review data together. Parkar NextGen Platform, for instance, comes with dashboards to help filter data for specific uses of varied IT audiences.

Automation is key to AIOps

While everyone understands the importance of automation, we have a long way to go before everyone embraces it completely. In an environment where data moves and grows beyond the human scale, it is critical to automate all tasks and orchestrate processes.

DevOps teams are now moving at lightning speeds to automate and orchestrate things and plug into the CI/CD toolchain. With the right processes and teams, you will be able to know who owns the code, what is its impact on production, identify developer backlog and measure productivity effectively. All you need to do is automate and orchestrate the things they do across siloed tools.

Parkar NextGen Platform

The steps mentioned above identify and iterate just a few of the key elements of developing an effective AIOps tools strategy. Alternatively, you can leverage Parkar’s robust platform to get a better grip on your IT functions and align them with your business goals.

Broad business benefits:

  • Enriched AIOps data
  • The clarity to prioritize issues
  • Automate service assurance through a model-driven approach
  • Excellent algorithmic correlation
  • Cognitive insights to process data more efficiently

Those who have used the platform have experienced incredible results. Primary Operational Benefits include:

  • Reduction in tedious manual tasks: 74%
  • Faster MTTR: 67%
  • Anomaly Detection: 58%
  • Casualty Determination: 48%
  • Alert co-relation and inferencing: 49%
  • Data insights: 73%
  • Noise Reduction: 28%
  • Root Cause Analysis: 68%


Closing Thoughts

AIOps adoption is critical for successful digital transformation. It’s time you realized the full potential of AIOps and see how it can put you on the road to success with machine learning, big data, and analytics. Request a demo or call us today and we would be happy to take you on a tour of amazing possibilities. What we promise is greater efficiency. The question is- Are you ready to embrace AIOps?

Right Strategies for Microservices Deployment

974 608 Parkar Consulting & Labs

Microservices architecture has become very popular in the last few years as it provides high-level software scalability. Although organizations embrace this architecture pattern, many still struggle with creating a strategy that can overcome some of the major challenges such as decomposing it to the microservices-based application.

At Parkar Consulting & Labs, we help our clients deploy microservices application to reduce operational costs and have high availability of the services. One such success story is of the largest telecom company in the US, where we successfully did a RESTful microservices based deployment.

In this blog, we will share some of the most popular microservices deployment strategies and look at how organizations can leverage it to attain higher agility, efficiency, flexibility, and scalability.

Microservices Deployment challenges

Deployment of monolithic applications implies that you run several identical copies of a single, usually large application. This is mostly done by provisioning N servers, be it physical or virtual, and running the application’s M instances on each one. While this looks pretty straightforward, more often than not, it isn’t. However, it is far easier than deploying microservices applications.

If you are planning to deploy a microservices application, then you must be familiar with a variety of frameworks and languages these services are written in. This is also one of the biggest challenges since each one of these services has its specific deployment, resource requirements, scaling, and monitoring requirements. Add to it, deploying services has to be quick, reliable, and cost-effective!

The good news is that several microservices deployment patterns can be easily scaled to handle a huge volume of requests from various integrated components. Read this blog to find out which one suits your organization the best and make the deployme\

Microservices Deployment Strategies

1. Multiple Service Instances per Host (Physical or VM)

Perhaps the most traditional approach to deploying an application is the Multiple Service Instances per Host pattern. In this pattern, software developers’ provision single or multiple physical or virtual hosts and run several service instances on each one. This pattern has few variants, including a variant for each service instance to be a process or run several service instances in the same process.



Relatively efficient resource usage since multiple service instances use the same server and its operating system.

Deployment of a service instance is also relatively fast since you just have to copy the service to a host and run it.

For instance, if the service is written in Java then you just have to copy the JAR or WAR file or the source code if it is written in Node.js or Ruby.

Starting service on this pattern is also quick since there is no overhead. In case the service has its process, you can just start it else you can also dynamically deploy into the container or restart it if the service is one of many instances running in the same container process or process group.


  • Little or complete lack of control on service instances unless each instance is a separate process. There is no way you can limit the resources each instance utilizes. This can significantly consume the memory of the host.
  • Lack of isolation if several service instances run in the same process. This often results in one misbehaving service interrupting other services in the same process.
  • Higher risks of errors while deployment since the operations team that deploy it needs to know the minutest of details of the services. Therefore, information exchange between the development team and the operations is a must for removing all the complexity.

2. Service Instance Per Host (Physical or VM)

Service Instance per Host Pattern is another way to deploy microservices. This allows you to run each instance separately on its host. This has two specializations: Service Instance per Virtual Machine and Service Instance per Container.

Service Instance per Virtual Machine Pattern allows you to package each service as a virtual machine (VM) images like Amazon EC2 AMI. Each instance is a VM that is run using that VM image. One of the popular apps using this pattern is Netflix for its video streaming service. To build your own VMs, you can configure a continuous integration server like Jenkins or use packer.io


One of the biggest benefits of using Service Instance per Virtual Machine pattern is that it uses limited memory and cannot steal resources from different services since it runs in isolation.

It allows you to leverage mature cloud infrastructure such as AWS to take advantage of load balancing and auto-scaling.

It seals your service’s implementation technology since the service becomes a black box once it has been packaged as a VM. It makes deployment a lot simpler and reliable.


  • Since VMs usually come in fixed sizes in a typical public IaaS, it is possible that it is not completely utilized. Less efficient resource utilization also ultimately leads to a higher cost of deployment since IaaS providers generally charge for VMs irrespective of whether they are idle or busy.
  • Deployment of the latest version is generally slow. This is because VM images are slow to create and instantiate due to their size. This drawback can often be overcome by using lightweight VMs.
  • Unless you don’t use tools to build and manage the VMs, Service Instance per Virtual Machine pattern can often be time-consuming for you and your team. This is usually a tedious process, but the good news is that the issue can be resolved by using various solutions such as Box fuse.

3. Service Instance per Container

In this pattern, each service instance operates in its respective container, which is a virtualization mechanism at the operating system level. Some of the popular container technologies are Docker and Solaris Zones.

For using this pattern, you need to package your service as a filesystem image comprising the applications and libraries needed to execute the service, popularly known as a container image. Once the service is packaged as a container image, you then need to launch one or more containers and can run several containers on a physical or virtual host. To manage multiple containers many developers like to use cluster managers such as Kubernetes or Marathon.


Like Service Instance per Virtual Machine, this pattern also works in isolation. It allows you to track how many resources are being used by each container. One of the biggest advantages over VMs is that containers are lightweight and very fast to build. Since there is no OS boot mechanism, containers can start quickly.


Despite rapidly maturing infrastructure, Service Instance per Container Pattern is still behind the VMs infrastructure and is not as secure as VMs since they share the kernel of the host OS.

Like VMs, you are responsible for all the heavy lifting of administering the container images. You also have to administer the container infrastructure and probably the VM infrastructure if you do not have a hosted container solution such as Amazon EC2 Container Service (ECS).

Also, since most of the containers are deployed on an infrastructure that is priced per VM, it results in extra deployment cost and over-provisioning of VMs to cater to an unexpected spike in the load.

4. Server-less Deployment

Server-less deployment technology is another strategy for micro-services deployment and it supports Java, Node.js, and Python services. AWS Lambda is a popular technology used by developers around the world. In this pattern, you need to package the service as a ZIP file and upload it to the Lambda function, which is a stateless service. You can also provide metadata which has the name of the function to be invoked when handling a request. The Lambda function automatically runs sufficient micro-services instances to handle requests. You are simply billed for each request based on the time taken and the memory consumed.


The biggest advantage of server-less deployment is the pricing since you will only be charged based on the work your server performs.

It frees you from any aspect of the IT infrastructure such as VMs, containers, etc., giving you more time to focus on the development of the application.


The biggest challenge of server-less deployment is that it cannot be used for long-running services. All requests have to be completed within 300 seconds.

Also, your services have to be stateless since the Lambda function might run a different instance for each request.

Services need to be in one of the supported languages and must launch quickly else it might time out and terminate.

Closing thoughts 

Deploying a micro-services application can be quite overwhelming without the right strategy. Since these services are written in a variety of frameworks and languages, each has its deployment, scaling and administering requirements. Therefore, knowing which pattern will suit your organization the best is absolutely necessary. We, at Parkar Consulting & Labs, have worked with scores of trusted customers to migrate their legacy monolithic applications to server-less architecture using Platform as a Service. The Parkar platform orchestrates the deployment and end-to-end management of the micro-services.

Greener Computing with Serverless Architecture

974 608 Parkar Consulting & Labs

Serverless computing is not new anymore and offers a world of benefits to developers and users alike. It’s an architecture and execution model where the developer gets the freedom and flexibility to build an application not having to worry about server infrastructure requirements. So while developers focus on writing application business logic, the operations engineers look into other nitty-gritty such as upgrades, scaling, server provisioning, etc. What began as Infrastructure-as-a-Service (IAAS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS) is rapidly changing into a Function-as-a-Service (FaaS) where users can explore and experiment without the limitations of traditional servers. What they get to focus on is hard-core development of products and pay only for the actual compute time and resources used instead of the total uptime.

How it works

Serverless computing is typically event-driven computing where a particular event leads to execution of a function. The function runs for about five minutes before getting discarded and everything that’s needed for it to run is provided by the public cloud infrastructure. Although this sounds simple, the fact that a function can, in turn, trigger more functions makes the entire process more complex. While from a traditional developer perspective, this could be perceived as zero control on aspects pertaining to server, modern developers are more than happy with serverless computing or FaaS. Today, all large cloud vendors offer serverless offerings that include BaaS (Backend as a Service) and FaaS products. As such the organization or individual that owns the system does not have to buy, rent or supply servers for the back-end code to work on.

Fig: Serverless Architecture (source: G2crowd))


Broad benefits

Green computing – A recent survey indicates that more than 75% of users will be on a serverless architecture in the next 18 months. According to Forbes, “typical servers in business and enterprise data centers deliver between 5 and 15 percent of their maximum computing output on average over the course of the year.” Also, there is a growing demand for larger data centers which would imply more physical resources and associated energy requirements. In typical ‘server’ settings, servers remain powered up even though they may be idle for long durations. Needless to say, this has a huge impact on the environment.

No doubt cloud infrastructure did help to a great extent in reducing this impact by providing servers on demand. However, this has adversely affected the situation since servers are left around without proper capacity management. By trying to make capacity decisions to make applications more sustainable to last for a longer period, enterprises end up being over-cautious and over-provision.

Luckily, the serverless architecture addresses this issue effectively and vendors provide enough capacity to manage the needs of customers in real-time thereby enabling a better use and management of resources across data centers.

To cite an instance, Parkar was responsible for evaluating and optimizing the ETL jobs for one of the largest telecom companies in the US. The rationale was to help reduce operational and maintenance costs and make it more efficient. It was observed that they were utilizing a third-party ETL product and expensive compute cycles on a server that was running 24×7 to perform these processes. By leveraging serverless architecture, the jobs were transformed into a utility-based model and while executing function runs, the cost was paid only for those ‘run instances’.

The outcome? Humungous savings, a happy customer and astounding results:


Lower costs – The easiest and perhaps the most effective way of offloading IT overhead is to go serverless. There is no investment towards server maintenance costs and the only time you pay is when you run your code. This also reduces operational costs. Besides, you save big on cloud administration cost and the cost of managing associated teams.

Fast deployment – There is a huge rise in developer productivity since they can now build, test and release in a highly agile environment. They don’t have to worry about the readiness of the infrastructure or when other elements pertaining to it are ready to be rolled out. An effort is being made by cloud service providers to provide a development environment that’s standard for all. A classic case in point was the announcement of AWS Lambda supporting C# in 2016. Although standards are known to impede vendor innovation, they also indicate a healthy inclination to embrace serverless architecture.

Reduced time to market – When faced with tight deadlines, serverless computing gives developers the advantage of running multiple versions of code simultaneously. This helps transform ideas into reality in the most effective manner. For instance, if they had to develop functionality that helps mobile users check their credit score as part of the mobile banking app, they would require several days before they could actually develop, test and deliver using traditional cloud IaaS models like AWS EC2. On the contrary, event-driven serverless computing with AWS Lambda could help them build the same functionality in just a few hours. In just a few clicks, they could develop functionality that’s foolproof, checked, flexible and scalable.

Built-in scaling – Built-in scalability is a huge advantage and enterprises never have to worry about over or under-provisioning while scaling policies. All you need to do is pay for the actual usage, and the serverless architecture infrastructure will expand or shrink as required.

Disaster recovery – Being a pay-per-use model, failover infrastructure comes as part of the CSP portfolio. Setting it up in paired regions of the geography in question is no big deal and comes at fraction of the cost of traditional computing in server settings. This facilitates a seamless switchover ensuring that the recovery time is virtually zero.

The scope

Experts continue to deliberate on the pros and cons of going serverless. As mentioned earlier, loss of control over infrastructure has been a major concern as the earlier settings allowed developers to customize or optimize the infrastructure as needed. Besides, some have voiced concern about security considering that multiple customers share the same serverless architecture. Measures are being implemented by vendors to address this issue by providing serverless offerings in a virtual private network. Also on offer is cloud portability to enable smooth transitioning from serverless offerings of one vendor to another. Cloud service providers are also involved in vulnerability scanning and penetration tests on infrastructure to help iron out compliance issues.

According to the Cloud Native Computing Foundation (CNCF), “there is a need for quality documentation, best practices, and more importantly, tools and utilities. Mostly, there is a need to bring different players together under the same roof to drive innovation through collaboration.”

Serverless adoption advances towards a point of maturity

As with the containers market, the current proliferation of open-source serverless frameworks should decrease and converge in the coming months. The consolidation is a major indication of how serverless adoption is maturing with time. Everyone was in awe of Amazon Web Services’ Lambda and before we knew all the big players were soon jumping onto the serverless bandwagon. Last year, Google along with 50 other companies including Pivotal, IBM, Red Hat and SAP introduced Knative the open-source network for cloud-native applications on Kubernetes. It was soon touted as developer-friendly software. Through its essential but reusable set of components, it came as a whiff of fresh air for those who were struggling with the difficult aspects of building, deploying and managing applications. The all-in-one orchestration platform was just what was needed for integrated teams to operate together. In times to come, this orchestration maturity will reach a whole new level, unleashing new possibilities for larger and more complex applications.

The emergence of sophisticated testing tools

When it comes to serverless applications, testing practices get even more complex. Serverless architecture brings together separate and distributed services, both tested independently as well as in combination to check the effects of their interaction with each service. In addition to this, it depends on cloud services and event-driven workflows that cannot be imitated easily for local testing. To address these testing challenges that are very different from those faced by conventional testing methods of a monolith approach, integration testing has emerged. This is just the beginning of an era of more sophisticated frameworks and tools that will change the game in a radical way.

From the climate perspective

4.5% of global electricity consumption in 2025 will be attributed to data centers, thus iterating the need for looking at ways to curtain consumption. When we think of big corporations like Microsoft, we can only imagine the scale at which they run their data centers.

They are focussing on the following areas to minimize environmental impact:

Operational efficiency – It leverages the power of multi-tenancy to increase hosting density (number of applications per server) to save on servers and related hardware, cooling, etc. As per a study by Microsoft, increasing load on a server from 10% to 40% increases energy requirements by a factor of 1.7. Increased server utilization in the cloud thus lowers the consumption of computing power.

Hardware efficiency – Microsoft in a bid to reduce power consumption can spend lavishly on making amends to design of server hardware. Many of its innovations are therefore given out in the form of open-source designs.

Infrastructure efficiency – Data centers are critically evaluating their Power Usage Effectiveness or PUE factor. While a value of 1 would mean entire energy is used only for computing and not for lighting, cooling, etc., large cloud providers need to work on improving their PUE factor. Microsoft, for instance, achieves an average of 1.25 for all their new Azure data centers.

Utilizing renewable energies

While Google is already operating with 100% renewable energy, Microsoft is inching its way to achieving its target of 60% renewables by 2019 and 70% by 2023.

In closing

The learning curve is steep when it comes to taking the FaaS journey. As Winston Churchill rightly said, “The farther back you can look, the farther forward you are likely to see.” The underlying network still has a long way to go before it matures into a solution that’s devoid of setbacks and complications. Until then, we need to focus on the myriad benefits of the operational environment it creates and how it’s changing the tide for developers worldwide ensuring a smoother sail towards their goals. Going serverless is certainly not going to be a cakewalk especially when traditional server settings dominate our systems. Though it needs to be looked at as an approach that should be embraced with open arms by developers, team leads, project managers and all concerned, being fully aware of what going serverless entails. What modern enterprises need is a well-planned architecture or else the initiative can quickly change into chaos.

To make your serverless initiatives work, call us today. Parkar Consulting is committed to helping you thrive on a serverless network and ensuring minimal impact on the environment through all its endeavors. We can help your development teams perform optimally keeping energy consumption to a bare minimum while enjoying increased efficiency. Call us today and we will tell you how.

Orchestrated PaaS: A Product-Centric Approach

974 608 Parkar Consulting & Labs

“We must indeed, all hang together, or most assuredly we shall all hang separately.” – Benjamin Franklin

Franklin reportedly issued this as a warning during the Revolutionary War of 1776.

Fast forward to the technological war room of the 21st Century, unity is still the key to victory, especially when it comes to the ‘Battle of the Clouds’!

Cloud technology is at chaotic crossroads. At the time when cloud adoption soared across industries, a plethora of companies jumped on the bandwagon with a short-sighted strategic approach. They quickly realized that the future of cloud computing does not lie in the implementation of multiple cloud resources but in the holistic adoption of cloud in all its forms. In other words, the value of cloud services is increasing exponentially as it functions as a single, cohesive, and orchestrating unit.

What is Cloud Orchestration?

Let’s take the example of a mechanical watch. How does it work? It involves the functioning of numerous interconnected gears that work in perfect harmony to measure the passage of time. The end result looks something like this:


The number of gears (or jewels) is directly proportional to the price of the watch. Why? Simply because every additional gear substantially improves the accuracy of the result. Fascinating stuff, isn’t it?

This is how cloud orchestration works. If you consider every independent cloud deployment and functionality as a gear, then orchestration is the process of bringing together every moving cloud part and tying them up in a single and monolithic workflow.

Benefits of disparate cloud resources working in tandem include the likes of high availability, scaling, failure recovery, and dependency management. DevOps can boost the speed of service delivery while reducing costs and eliminating potential errors in provisioning, scaling, and other processes.

In this case, the end result looks like this:


And this is the groundwork on which our story is based on.

PaaS – The Realm Beyond Cloud Orchestration

Platform as a Service or PaaS is a type of service deployment in the cloud that takes a product-centric approach and goes beyond orchestration. It aims to meet the basic infrastructure and platform needs of developers to deploy applications. They do not need to handle mundane tasks. Instead, they can use APIs to develop, test, and deploy industry solutions. For this purpose, they are generally hosted and deployed as web-based application-development platforms. This gives developers the flexibility to provide end-to-end or partial online development environments.

While it does help to orchestrate containers, the main function of Orchestrated PaaS lies in setting up choreographed workflows. This makes it relevant for software solutions that want to primarily focus on the development cycle of the software and the monetization of new applications. By deploying agile tools and techniques, companies can accelerate application development, reduce compartmentalization, increase collaboration, and boost scalability.

Apart from these, the primary reasons to implement an orchestrated PaaS strategy are:

  • Accelerated application development
  • Quicker deployment
  • Faster go to market
  • Organization-wide collaboration
  • Hybrid cloud flexibility
  • Enterprise-grade security

There are two basic types of Platform as a service deployment – ‘Service Orchestration’, and ‘Container Orchestration’.

Service Orchestration

These include public PaaS solutions and functions as a bundled package for individuals, startups, and small teams. Being public in nature, it does come with certain limitations in terms of the depth of integration it offers. Hence, it poses to be a difficult choice for organizations that are looking for company-wide standardization.

But, in situations where quick prototyping and deployment is needed with an ability to go past compliances, public PaaS solutions can come to the rescue.

Container Orchestration

Container orchestration includes private SaaS solutions that function as a closed system. It does not focus on where the product or application is running, rather concentrates on simply the running of the resulting service. For instance, the end result can be loading certain web pages without any latency.

But modern Enterprise IT has gradually brought about a change where they are concerned with the scale of application and not just the underlying system.

The Coveted PaaS Model

To better understand how a PaaS framework can serve certain business scenarios, here are certain cases of this model.

  • A single vendor owns every platform or application that is contained in the PaaS model.
  • Applications need to be developed from scratch and leverage a formalized programming model.
  • The services involved in the solution are common and stable.
  • All the roles of containers used in the business model are stable.
  • No industry-specific service or application is being used in the platform, and it is simple and easy to design and manage.

The whole idea of PaaS is to empower developers by helping them deliver value through their product without worrying about building a dedicated IT infrastructure.

Best Practices and Patterns of Orchestrated PaaS

The manner in which a PaaS system can be fundamentally orchestrated depends on its solution-specific application scenario, business model, and enterprise architecture. Based on this, integration patterns with other leading industry solutions can also vary. Various patterns in which PaaS can be implemented include:

  • Embedded PaaS

This is implemented within an industry solution and becomes a part of it. Examples of this include; a cloud-enabled integrated information framework. In such a system, only certain parts or functions of the whole system are deployed as PaaS solutions. The rest of the solution is not hosted on the cloud.

  • Value-added PaaS

Functions as ‘PaaS on an industry’ and includes industries that host value-added PaaS solutions that can be used by customers in tandem with their core industry offerings. Primary functions and infrastructures are maintained outside the cloud environment. Examples here include; a self-service telecommunications service delivery platform that is based on the cloud that empowers customers to quickly deploy value-added PaaS functionalities from the ground-up.

  • Bundled PaaS

The core function or solution of the industry is bundled together in the same PaaS environment. The end result is an industry-specific PaaS solution that empowers the entire business model of the company to function as an independent node in the ecosystem.

The World of Containers: Building Blocks of PaaS

In the elementary sense, containers are what have made PaaS possible in the first place. All the necessary code of a function can be bundled into a container, and the PaaS accordingly builds on to run and manage the application.


Although PaaS boosts the productivity of developers, they have little wiggle room. But, now, further technological development has made an autonomous existence of containers possible with leading software solutions, such as Docker, Kubernetes, and Red Hat OpenShift.

With these applications, developers can now easily define their app components and build container images. Apps can now run independently from platforms, paving the way for more flexible orchestration.

Software-Driven Container Orchestration

Here’s a close look at the various software that is making PaaS orchestration possible by functioning at the container level.

1. Docker

Docker is an open platform that is meant for developing, running, and delivering applications. It enables users to treat their infrastructure like a managed application. As a result, developers can quickly ship codes, test apps, and deploy them by reducing the time gap between writing and running codes.

Benefits of Docker for Paas Orchestration include:

  • Faster delivery of applications.
  • Easy application deployment and scaling.
  • Achieving higher density and running more workloads.
  • Eliminating environmental inconsistencies.
  • Empowering developer creativity.
  • Accelerating developer onboarding.

2. Kubernetes

Kubernetes is another popular container orchestration tool that works in tandem with additional tool sets for functions, such as container registry, discovery, networking, monitoring services, and storage management. Multiple containers can be grouped together and managed with a single entity to co-locate the main application.

Features of Kubernetes include:

  • Algorithmic container placement that selects a specific host for a specific container.
  • Container replication that makes sure that a specific number of container replicas are running simultaneously.
  • An auto-scaling feature that can autonomously tweak the number of running containers based on certain KPIs.
  • Resource utilization and system memory monitoring (CPU and RAM).

3. Red Hat OpenShift

This is a unique platform that is a combination of Dev and Ops tools that functions on top of Kubernetes. Its aim is to streamline application development and manage functions like deployment, scaling, and long-term lifecycle maintenance.

Various features of the tool include:

  • Single-step installation for Kubernetes applications.
  • Centralized admin control and performance optimization for Kubernetes operators.
  • Contains functions, such as built-in authentication and authorization, secrets management, auditing, logging, and integrated container registry.
  • Smart workflows, such as automated container build, built-in CI/CD, and application deployment.
  • Built-in service mesh for microservices.

In fact, Openshift has become the go-to platform to implement PaaS orchestration.

At Parkar, we recently came across a project where the client was looking to develop a next-gen platform that increased speed and incorporated

innovation in their existing technological ecosystem. Our developers used Openshift as the orchestrated container platform and significantly reduced the time to market.

The decision paid off with significant metrics and the following project results were realized:


It is safe to assume that successful cloud orchestration opens the door for a number of benefits for the entire cloud ecosystem. These include forced best practices, simplified optimization, unified automation, improved visibility and control, and business agility. The PaaS construct functions as a layered model to deliver specific applications and services. It also improves the end-result with abilities like rapid time-to-market, future-proofing, and investment protection to support all-round cloud-based digital transformation.

Application Containerization Assessment

974 608 Parkar Consulting & Labs

Containerization seems like the buzzword these days and I&O (Infrastructure and Operations) leaders globally are eagerly adopting container technology. As per Gartner, the containerization wave will sweep across organizations worldwide with 75% of them running containerized applications in production by 2022 as opposed to the current 30%. Having said that, the fact cannot be denied that the present container ecosystem is still in its nascent stage. There’s a lot to get out of containerized environments provided containerization is a good fit for your organization. Detailed assessment therefore becomes a mandate to ensure that you have a solid business case that makes the additional layer of complexity and cost incurred in deploying containers absolutely worth your efforts. It wouldn’t be wrong to say that running them in production, by far, seems like a steep learning curve that many are trying to comprehend.

The dilemma 

To containerize or not to containerize is one question that continues to plague the minds of many. While moving traditional monolithic workloads to the cloud seems like a great idea, organizations need to seriously ponder over whether moving the workload is indeed the right thing to do. Many are going by the ‘lift and shift’ the application into a virtual machine (VM) approach, but the pertinent question here is ‘does containerization help your case?’ When applied correctly, it will not only modernize legacy applications but also create new cloud-native ones that run consistently across the entire software development life cycle. What’s even better is that these new applications are both agile and scalable. While deploying containers in production environments, the I&O teams need to mitigate operational concerns pertaining to their availability, performance and integrity. At Parkar, we look at all your deployment challenges critically. We’ve identified the key elements that can help you decide how eligible your applications are for containerization.

Here’s a quick lowdown on the assessment. Take a look.

Now lets deep-dive into more details.

Is your platform a containerized version?

This should not be so difficult considering the fact that vendors have already taken care of that. Commonly used platforms such as Node.js, Drupal, Tomcat and Joomla have taken care of the nitty-gritties to ensure that the app you use offers scope for digital transformation and gets converted to be adapted effortlessly into a containerized environment. For starters, begin with an inventory of all internally-developed applications. Check if the software being used allows containerization. If yes, you can extract the application configuration, download its containerized version and Voila; you are good to go. The same configuration can be fine-tuned to run in that version and can be subsequently deployed in a shared cluster in a configuration that is even cheaper than its predecessor.

Do you have containerized versions of 3rd party apps?

With the vast majority of legacy apps being converted into containerized versions, third party vendors are also realizing the benefits of jumping onto the containerization bandwagon. When you choose to containerize instead of choosing VMs, you also eliminate the need of having OS and bearing its license fee. This leads to better cost management as you avoid paying for unnecessary stuff. As a result, vendors too are now offering containerized versions of their products. Commercial software is one of them. Classic case in point- Hitachi offering SAN management software on containers. This is a value-add to their existing full-server versions. Infrastructure servers deployed at data centers are good examples of application containerization. Talk to your vendors and they will tell you if they offer any. For all you know, the road to application containerization may be smoother than you think.

Do you have a stateless app?

When an application program does not save client data that gets generated in one session to be used for a future session even if it is for the same client, it is called as a stateless app. The configuration data so stored is often in the form of temporary cache instead of permanent data on the server. Typically, Tomcat tiers and many other web front ends are good examples of stateless apps where the role of tiers is merely to do processing. As you take away the stateless tires of any application, they automatically become eligible for containerization due to the flexibility they attain. Rather than being run at high density, they can now be containerized to facilitate simpler backups and configure changes to the app. While these are good targets, storage tools such as ceph, Portworx and Rex-Ray also make good candidates, except that they will require a lengthier process to containerize. Post the makeover, they become great targets.

Is your app part of a DevOps and CI/CD process?

If the answer is yes, then migrating to containers would be a cakewalk for you. All you need to do is package them in containers and integrate them with your servers. As you gradually gain confidence that the deployment has been well received and the app is working as desired, you can bring container orchestration platforms into the picture and enjoy a host of advantages, top on the list being resilience and efficiency. Companies have started realizing the benefits of app containerization and have started modifying their existing CI/CD pipeline so as to create a more efficient and robust infrastructure. Apart from the obvious benefits, containerization goes a long way in testing and deployment of new code and even retrieves the ones that are not performing well. For those who thrive on agile development, this feature is definitely a huge savior.

Are you using a pre-packaged app?

It’s easy to containerize an application if it is already packaged as a single binary or a JAR file since both are fairly flexible. What’s common about Java apps and JAR files is that both can be easily changed to their containerized versions apart from the fact that they carry their typical JRE environment into the container during the process. This ensures faster and simpler deployment and also gives users the freedom to run various versions of Java runtimes alongside on the same servers. This is possible purely because of the isolation that containers offer.

How secure is the environment?

A container-based application architecture comes with its own set of security requirements. Container security is a broad term and includes everything from the apps they hold to the infrastructure they depend on. The fact that containers share a kernel and don’t work in isolation makes it important to secure the entire container environment. The Linux 3.19 kernel for instance, has about 397 system calls for containers clearly indicating the size of the attack surface. A small breach in the security of a single one would in turn jeopardize the security of the entire kernel. Also, containers such as Docker containers have a symbiotic arrangement and designed to build upon each other. Security should be continuous and must gel well with enterprise security tools. It should also be in line with existing security policies that balance the networking and governance needs of containers. It is important to secure the containerized environment across the entire life cycle that includes but is not limited to development, deployment and the run phase. As a rule of thumb, products that offer whitelisting, behavioral monitoring and anomaly detection must be used to build security in the container pipeline. What you get is a container environment that can be scaled as required and completely trusted.

Resource Requirements

As opposed to running VMs that require more resources, containers occupy just a miniscule portion of the operating system and are therefore less resource-intensive. Several containers can be easily accommodated on a single server with ease. However, there will be edge cases where scaling of multiple containers may be necessary in order to replace a single VM which would also mean you could be saying goodbye to potential savings on resources. One VM would be equivalent to an entire computer, and if you were to divide its functions into 50 distinct services, you would actually be investing in not one but 50 partial copies of the operating system. Now that’s something you definitely need to consider before deciding if containerization is for you. You get it? Or we could go on and on with the number crunching.

Other considerations

There are several other considerations that determine if your apps are containerization-worthy. You need to take into account several factors such as storage, networking, monitoring, governance and life cycle management. Each has a vital role to play and can be a critical component in the decision-making process.

Ask the experts

Parkar recently undertook an application modernization project for a prominent healthcare company where it was tasked with the evaluation of multiple applications to check their readiness for containerization. We worked on one of the critical business applications and chalked out a roadmap to modernize and containerize it without compromising security and availability. We migrated the application to OpenShift platform with multiple containers for their frontend and backend layers. The application was scaled both horizontally and vertically.

Here’s what we achieved:



Summing up

Containerization comes with a world of benefits. From allowing you the convenience of putting several applications on a single server to support a unified DevOps culture, they give you the agility and power to perform better in a competitive environment. Since they run on an operating system that’s already booted up, they are fast and ideal for apps that require spun up and down every now and then. Being self-contained they are portable and can be easily moved between machines.

The modern organizations rely on DC/OS to host containerized apps. The reason being that this method consolidates your infrastructure into a single logical cluster that offers incredible benefits that include fast hosting, efficient handling of load balancing, and automatic networking of containers. It allows teams to estimate the resources required and help reduce the operating costs for existing applications.

If you wish to know if containerization is right for you and want to unleash greater efficiencies, contact us today.

© 2018 Parkar Consulting Group LLC.