Feeling small and cozy – while being big and capable

About two months ago I started my new Cloud journey in a company that has grown - and grows - very fast. Initially I had an image of a small, nimble and modern company inside my head - and it was a surprise to realize that Solita has 1500+ employees nowadays. But has it become a massive ocean-going ship, too big to steer swiftly? A corporation slowly suffocating all creativity and culture?

Fortunately not. As our CEO Ossi Lindroos said (adapting / quoting some successful US growth company) in our starter bootcamp day:

“One day we will be a serious and proper company – but that day is not today!”

Surely, Ossi is not saying that we should not take business seriously and responsibly at all. Or that we should not act like a proper company when it comes to capabilities towards customers – or ability to take care of our own people. We do act responsibly and take our customers and our people seriously. But instead the idea – as I interpret it – is that we have that caring small community feel even when growing fast – and we want to preserve it no matter how big we grow.

Can a company with good vibrations preserve the essentials when it grows?

Preserving good vibrations

Based on my first weeks I feel that Solita has been able to maintain low hierarchy, open culture with brave and direct communication, not to forget autonomous and self-driven teams, people and communities. Like many smaller companies inside a big one, but sharing an identity without siloing too much. Diversity with unity.

I started in Solita Cloud business unit and the first thoughts are really positive. Work is done naturally crossing team or unit boundaries. Teams are not based on single domain expertise, but instead could act as self-preserved cells if required. Everyone is really helpful and welcoming. Company daily life and culture is running on Slack – and there you can easily find help and support without even knowing the people yet. And you get to know people on some level even without meeting them: that guy likes daily haikus, that girl listens to metal music etc.

“One day we will be a serious and proper company – but that day is not today!”

Petrus Enjoying Good Vibrations

Some extra muscle

And size is not all about downsides. Having some extra muscle enables things like getting a proper, well-thought induction and onboarding to new people that starts even before the first day with prepackaged online self-learning – and continues with intensive bootcamp days and self-paced, but comprehensive to-do-lists, that give a feeling that someone has put real effort on planning all this. Working tools are cutting-edge, whether choosing your devices and accessories or using your cloud observability system.  And there is room for the little bonus things as well, such as company laptop stickers, caps, backpacks and different kind of funny t-shirts. Not to mention all the health, commuting and childcare benefits.

And for customers, having some extra muscle means being a one-stop shop yet future-proof at the same time. Whether the needs are about leveraging data or designing and developing something new, or about the cloud which enables all this, customer can trust us. Now and tomorrow. Having that small community feeling and good vibrations ensures that we’ll have brilliant, motivated and healthy people helping our customers in the future as well.

Culture enables personal growth

And when the culture is supporting and enabling, one can grow fast. A while ago, I used to be a rapid-fire powerpoint guy waving hands like windmills – and now I’m doing (apologies for the jargon) Customer deployments into the Cloud using Infrastructure-as-Code, version control and CI/CD pipelines – knowing that I have all the support I need, whether from the low-threshold and friendly chat community of a nimble company, or a highly productized runbooks and knowledge bases of a serious and proper company. Nice.

Now, it’s time to enjoy some summer vacation with the kids. Have a great summertime you all, whether feeling small and cozy or big and capable!

Is cloud always the answer?

Now and then it might feel convenient that an application should be transferred to cloud quickly. For those situations this blog won’t offer any help. But for occasions when the decision is not yet made and a bit more analysis is required to justify the transformation, this blog post will propose a tool. We believe that often it is wise to think about various aspects of the cloud adoption before actually perform it.

For all applications there will be a moment in their lifecycle that the question whether the application should be modernised or just to be updated slightly. The question is rather straightforward. The answer might not as there are business and technological aspects that should be considered. Having the rational answer available is not easy task. Cloud transformation should have always business need as well as it should be technologically feasible. Many times there might be an interest to make the decision rather hasty and just move forward due to the fact that it is difficult to gather the holistic view to the application. But just neglect the rational analysis because it is difficult might not always be the suitable path to follow. Success in cloud journey requires guidance from business needs as well as technical knowledge.

To address this issue companies can formalize cloud strategy. Some companies find it as an excellent choice to move forward as during the cloud strategy work the holistic understanding is gathered and guidance for the next steps is identified. Cloud strategy also provides the main reason why cloud transition is supporting the value generation and how it is connected to the organisation strategy. However, sometimes the cloud strategy work might be contemplated to be too large and premature activity. In particular when the cloud journey is not really started and knowledge gap might be considered to be too vast to overcome and it is challenging to think about structured utilisation of the cloud. Organizations might face challenges in maneuvering through the mist to find the right path on their cloud journey. There are expectations and there are risks. There are low-hanging-fruits but there might be something scary ahead that has not even have a name.

Canvas to help the cloud journey

Benefits and risks should be considered analytically before transferring application to the cloud. Inspired by Business Model Canvas we came up a canvas to address various aspects of the cloud transformation discussion.  Application Evaluation Canvas (AEC) (presented in figure 1) guides the evaluation to take into account aspects widely from the current situation to expectations of the cloud.

 

cloud transformation

Figure 1. Application Evaluation Canvas

The main expected benefit is the starting point for the any further considerations. There should be a clear business need and concrete target that justifies the cloud journey for that application. And that target enables also the work to define dedicated risks that might hinder reaching the benefits. Migration to cloud and modernisation should always have a positive impact on value proposition.

The left-hand side of the canvas

The current state of the application is addressed with the left-hand side of the Application Evaluation Canvas. The current state is evaluated through 4 perspectives;  key partners, key resources, key activities and cost related. Key Partner section advice seeking answers to questions such who are the ones that are working with the application currently. The migration and modernisation activities will impact those stakeholders inevitably. In addition to the key partners, also some of the resources might be crucial for the current application. For example in-house competences that relates to rare technical expertise. These crucial resources should be identified. Furthermore, not only competences are crucial but also lots of activities are processed every day to keep the application up-and-running. Understanding about those will help the evaluation to be more meaningful and precise. After key partners, resources, and activities have been identified, the good understanding about the current state is established but that is not enough. Cost structure must also be well known. Without knowledge of the cost related to the current state of the application the whole evaluation is not on the solid ground. Costs should be identified holistically, ideally not only those direct costs but also indirect ones.

…and the right-hand side

On the right-hand side the focus is on cloud and the expected outcome. Main questions that should be considered are relating to the selection of the hyperscaler, expected usage, increasing the awareness of the holistical change of the cloud transformation, and naturally the exit plan.

The selection of the hyperscaler might be trivial when organisation’s cloud governance guides the decision towards pre-selected cloud provider. But for example lacking of central guidance or due to the autonomous teams or application specific requirements might bring the hyperscaler selection on the table. So in any case the clear decision should be made when evaluate paths towards the main benefit.

The cloud transformation will affect the cost structure by shifting it from CAPEX to OPEX. Therefore realistic forecast about the usage is highly important. Even though the costs will follow the usage, the overall cost level will not necessary immediately decrease dramatically, at least from the beginning the migration. There will be an overlapping period of current cost structure and the cloud cost structure as CAPEX costs won’t immediately decrease but OPEX based costs will start occurring. Furthermore the elasticity of the OPEX might not be as smooth as predicted due to the contractual issues; preferring for example annual pricing plans for SAAS might be difficult to be changed during the contract period.

The cost structure is not the only thing that is changing after cloud adoption. The expected benefit will be depending on several impact factors. Those might include success in organisational change management, finding the required new competences, or application might require more than lift-and-shift -type of migration to cloud before the main expected benefit can easily be reached.

Don’t forget exit costs

In the final section of the canvas is addressing the exit costs. Before any migration the exit costs should be discussed to avoid possible surprises if the change has to be rolled back.  The exit cost might relate to vendor lock-in. Vendor lock-in itself is vague topic but it is crucial to understand that there is always a vendor lock-in. One cannot get rid of vendor lock-in with multicloud approach as instead of vendor lock-in there is multicloud-vendor lock-in. Additionally, orchestration of microservices is vendor specific even a microservice itself might be transferable. Utilising somekind of cloud agnostic abstraction layer will form a vendor lock-in to that abstraction layer provider. Cloud vendor lock-in is not the only kind of lock-in that has a cost. Utilising some rare technology will inevitable tide the solution to that third party and changing the technology might be very expensive or even impossible. Furthermore, lock-in can have also in-house flavour, especially when there is a competence that only a couple of employees’ master. So the main question is not to avoid any lock-ins as that is impossible but to identify the lock-ins and decide the type of lock-in that is feasible.

Conclusion

As a whole the Application Evaluation Canvas can help to gain a holistic understanding about the current state. Connecting expectations to the more concrete form will to support the decision-making process how the cloud adoption can be justified with business reasons.

Log Format in Modern Architectures

In this blog, we will take a look at different modern architectures and systems, how centralized log management should be approached regarding these setups and what to take into account.

Modern solutions can grow rather complex and can carry a lot of legacy. That’s why streamlining your logs and centralizing them is quite frankly the only option. But when we have the log data in order, it’s quite easy to transform log data into dashboards, for example to visualize data like success percentage from HTTP responses or API request rate. It’s also much easier to implement or integrate systems like SIEM into your architecture, when you already have a working centralized logging.

System Complexity

The more complex your system is, the more it can benefit from centralized logging and it’s monitoring. If it’s done well that is. A good example on when centralized logging is almost mandatory, is any type of microservice – based architecture. Microservices or microservice architecture, is an architectural style in which application is a collection smaller services. These services have specific functionalities and can be independently deployed, tested and developed. Comparing this to microservices counterpart, monolithic architecture, which is a single unit running everything, we can avoid issues like single bug breaking whole system or updating one thing requires a full deployment, risking outages. With microservices a bug is limited to a single service and functionality. Updates, like security patching, can be done to a single service without disrupting the system. Below is a diagram on how microservices can work for example in an e-commerce application.

 

Microservices have their own downsides, like more complex deployments where instead of one service you must take care of possibly hundreds of individual services and their integrations. Orchestration tools like Kubernetes, OpenShift and Docker Swarm can help but these too bring additional complexity. It can also be a pain to troubleshoot, where a misconfiguration in one service can cause an error in another. Therefore, having applications logging with unique identifiers and events is important in more complex systems.

Also, a common situation is a hybrid solution, where let’s say Kubernetes, is managed by a cloud provider while databases still exist on-premises. Staying on top of what’s happening in these kinds of setups is challenging, especially when old systems can cause some legacy related issues. But all hope is not lost, by following the same rules in both the cloud and on-premises, these hybrid solutions can be tamed, at least when it comes to logging. Below is an example of an hybrid environment, where part of the solution is run on AWS and some are still on-premise. It’s quite simple to integrate all systems to centralized logging, but it becomes more important to have log format that all services will follow due to system complexity.

Another topic worth to discuss is SIEM (security information and event management). Many companies have a requirement to track and manage their security events and know what is going on in their system. Now managing SIEM isn’t an easy task, far from it. Anyone who works with it, needs to know what they want to follow, what they need to react to and how to get that information out of the system. Usually, audit logs are delivered to SIEM in a specific format, which enables SIEM to understand how important and critical each log is. If logs are formatted and implemented properly, implementing or integrating your logging to SIEM shouldn’t be an issue. But if not, delivering raw audit log can quickly raise costs in size and in the amount of work required to get it running.

 

Standard log format

Usually, you need to know what kind of data you want to log. While many services provide metrics out of the box for easy integrations, usually logs need more attention to be useful. Each log should follow a standard log format. Now imagine if each service would have totally different log format. Issue is not only that there would be a huge number of fields but that those fields might overlap. If a field is overlapping and the data types are different, one of the log lines will not be indexed. Format could include fields like:

  1. Service name
  2. Timestamp
  3. Unique identifier
  4. Log level
  5. Message

Creating your own log format makes most sense when you control logging configuration in your software. For third party software, it’s not always possible to modify their logging configuration. In this case it’s usually best to filter and mutate log data based on certain tags or fields. This can get more complex with hybrid environments, but it’s highly beneficial, when everything is following the same format, even if only partly. It can also be beneficial to have these logs in separate index, to avoid possible conflicts with fields. Using features like dynamic mapping in Elasticsearch can make our life and scaling easier in the future.

Unique Identifier

In addition to standard log format, it is useful to have a unique identifier, especially with microservices, which we will talk about later. This identifier is attached to incoming request, and it stays the same while the request moves through the system. This comes handy when troubleshooting, where the first thing is to identify the unique ID in the log. By searching for this ID, it’s possible to track requests trail from the moment it came to the system to where it failed or they did something weird. Identifier can be something like a UUID in a header of an HTTP request or something more human readable. Having standard format and unique id means that the organization or development unit needs to work with the same standard requirements and guidelines. While our typical log format example provides important information like timestamp and service name, we need more information in our message field (or in some other field). Something simple as HTTP responses are usually a good place to start and are easy to filter when looking for errors.

Log levels

Log levels are rather self-explanatory, for example most logging frameworks have the following log levels:

  • ERROR
  • WARN
  • INFO
  • DEBUG
  • TRACE

If our earlier blog tried to explain anything, it should be that log levels like TRACE and DEBUG shouldn’t be logged, except when actual troubleshooting is needed. It’s good to plan your levels so, that only ERROR and WARNING are needed to notice any issues with your software and INFO shouldn’t be just renamed DEBUG log. Having some custom levels, like EVENT, can help to filter logs more efficiently and quickly describe what the log is about.

Event logs

To improve the ability to track and troubleshoot your applications, event logs are really handy. They also have high business value, if event logs are used to create event-driven architecture. Having event logs requires work (again) from the application team. It’s more difficult to modify third party applications, as maintaining those changes requires dedication. Event logs should contain information on what type of event has happened in the application. These events can be their own log level, like EVENT, or just be included in the message. In a larger system, having events tied with the unique identifier helps to keep track of users and their process through the system. Even if events aren’t their own special category, all applications should log messages that make sense to developers and people reliant on said information. Implementing event information and unique identifiers is a large task and needs to be done unitedly across the whole system. But the payoff is clear visibility to the system through logs and the ability to leverage log data for monitoring, troubleshooting and security purposes. When using log4j2 in java based applications, it’s possible to use EventLogger class, which can be used to provide a simple mechanism for logging events in your application.

Conclusion

Logging is easy when you only have one piece of software or just a small system to operate. But the higher we grow and more we stack up our stack, more difficult it gets to see everything that’s happening. That’s why we need to but our trust into more software, that can handle all the information for us. Having a proper logging is crucial in this modern day and modern architecture but not that many are able to take advantage of it. Most of the centralized log management tools can be used to visualize and create dashboards from your log data, turning the flood of logs into something useful rather easily.

Information Security Assurance Frameworks

There are many ways to demonstrate the maturity level of information security management. National and international standards and frameworks can be used as criteria for measuring the level of information security. Here is a brief overview of common frameworks in use.

ISO/IEC 27001

International Organization for Standardisation (ISO)  and International Electrotechnical Commission (IEC) maintain and publish the ISO/IEC 27001 standard on information security management system (ISMS) and its requirements. It is part of the 27000 family of standards which address information security. ISO/IEC 27001 is probably the most famous one, because it is the one that can be certified. It emphasises risk-based approach, continuous improvement and commitment from the top-management.  The standard itself has seven mandatory clauses and Annex A, which defines controls in 14 groups to manage information security risks. ISO/IEC 27001 certification requires a third-party audit by an independent certification body, so certified organisations can be trusted to have an implemented and maintained information security management system. 

It should be noted that the audit does not necessarily provide assurance on how well the controls have worked, merely that they exist. It is also a good idea to examine the scope of the management system, as it might cover only some of the operations of the organisation. Statement of Applicability is another document that should be examined; it defines which controls have actually been implemented and which have been left out and why. 

Note: The standard is being reviewed and based on changes in ISO/IEC 27002  (implementation guide of the controls in Annex A) there will be some changes.

Mandatory clauses Annex A
Context of the organisation Information security policies
Leadership Organisation of information security
Planning Human resource security
Support Asset management
Operation Access control
Performance evaluation Cryptography
Improvement Physical and environmental security
Operations security
Communications security
System acquisition, development and maintenance
Supplier relationships
Information security incident management
Information security aspects of business continuity management
Compliance

 

Assurance Reports

ISAE 3000, ISAE 3402 and SOC 2® are standards and frameworks for assurance reports. Assurance reports provide independent attestation that a service provider has adequate controls of the subject matter, in this case information security. They are more common in the United States and Canada, but also used in Europe. Cloud providers or other service providers utilising cloud services often have some assurance report.

ISAE 3000 

International Standard on Assurance Engagement 3000 is a standard which defines how assurance engagements other than financial audits should be conducted. It does not define any controls in itself, but rather how the auditing should be done. The reader of an ISAE 3000 assurance report automatically knows that the assurance is conducted objectively and independently in a professional manner. It is up to the subject matter and the criteria whether it provides assurance and what sort of assurance on information security.

ISAE 3402

ISAE 3402 is also an international standard on assurance engagements, it focuses on internal controls of a service provider. Like ISAE 3000, it does not define any exact criteria to be used, but they have to be applicable to the subject matter. 

SOC 2®

SOC 2® or System and Organisational Controls 2 is AICPA’s (American Institute of Certified Public Accountants) framework for information security assurance for service providers. The abbreviation should not be confused with Security Operations Center! It uses Trust Service Criteria (TSC) as the criteria used to assess the level of information security. The TSC includes requirements on security, availability, processing integrity, confidentiality and privacy. For a SOC report, the security requirements are mandatory.  An official SOC 2® report can only be given by an AICPA’s certified public accountant, which is bypassed by the rest of the world with ISAE 3000 reports that are compliant with the SOC 2® framework. 

ISAE 3000, ISAE 3402 and SOC 2® can be done either as Type I or Type II reports. Type I provides assurance that the controls are described and suitable and is similar to an ISO/IEC 27001 certification. Type II provides assurance that, in addition to being described and suitable, the controls have also operated effectively during the audit period (typically 12 months). For example, for Type I report the auditor might inspect that a policy and procedure for incident management exists. For Type II report the auditor would also inspect a sample of incidents that occurred during the audit period to ensure the procedure was followed. 

It is worth noting that the actual reports are not publicly available, although there might be a summary of such assessment having been done. However, the reports can be requested from business partners or when negotiating possible partnerships. It also requires some level of expertise in security and auditing to assess controls descriptions and testing procedures in the reports. 

KATAKRI and PITUKRI

KATAKRI or Kansallinen turvallisuusauditointikriteeristö, literally national security audit criteria, is a comprehensive criteria published by the Finnish national security agency. It consists of three domains: security leadership, physical security and technical security. Katakri is used to assess the suitability of an organization to handle officials’ classified information, but as a public criteria can also be used by anyone as a benchmark criteria. 

PITUKRI or Pilvipalveluiden turvallisuuden auditointikriteeristö, literally cloud service security audit criteria is meant for assessing cloud service security in the context of Finnish requirements. 

PCI-DSS

PCI-DSS is an abbreviation for Payment Card Industry Data Security Standard. It is an international standard used to assess the security related to payment card transactions. It was created by major credit card companies and maintained by Payment Card Industry Security Standards Council. Compliance with the PCI-DSS is required in practice from businesses that process credit or debit card transactions. The standard has 12 requirements divided into six groups: secure networks and systems, cardholder data protection, vulnerability management, access control, network monitoring and testing and information security policy. 

The process of PCI-DSS compliance is a three step process of assessing, remediating and reporting. Assessing means identifying cardholder data and relevant assets and processes which are analysed to recognize vulnerabilities. Remediating means fixing the vulnerabilities which is followed by reporting to banks and card brands. Compliance with the standard requires an annual scoping of anything that has anything to do with the cardholder data. The assessment requires a qualified security assessor. 

What to think of certificates and information security assurance?

The importance of information security assurance depends on the business done with the party having (or not having) them. If your business partner, especially on the vendor side, has anything to do with processing or storing your information and data, you should be interested in their information security controls. And if you are providing such services, clients will come easier if they are assured their data is safe and secure. Certifications and assurance reports can also reduce the number of audits: every business partner does not have to do vendor audits if there is independent assurance provided.

As for vendor relationships, information security frameworks might have requirements for vendors and suppliers. Although the responsibility for these controls will be on the certificate holder, they might have effects on business partners too.

If you want to do business with public sector, there will probably be national regulation and requirements. For example, with Finnish public sector attention should be paid to possible Katakri requirements such as related to physical security and doing confidential work in Katakri approved areas. 

Trustworthy assurance requires independent and accredited parties to provide them, such as accredited certification body for ISO/IEC 27001 or CPA for ISAE 3000. The party providing assurance or certification should not provide consultation on the subject, at least not for the customer that is being certified by them. If implementation help is needed, another party should be used. For example, if you want to get ISO/IEC 27001 certified, Solita can help you in the implementation and then a certification body can conduct the audit and grant the certificate.

Most importantly everyone should be aware that certifications and assurance reports do not guarantee impenetrable security against breaches and incidents. Suppliers, customers and partners with a certificate or an assurance report are, however, more likely to be better prepared to recognise, mitigate and handle breaches and incidents when they occur. To get the most out of information security assurance, all interested parties should also know how they are achieved and what subjects they address. 

Cloud-technology is a tool

Us engineers are eager to get our hands dirty and dive into difficult architectural- and implementation tasks. We love to speak about technology and how to implement wonderful constructs. Good architecture and implementation is crucial, but we should not forget to put the customer to the spotlight. Do we have a solid business case and most important where is the value?

To project hardened seniors reading this, what would resonate in the manner to get you chills.

You know the feeling, when things really click. Your peer colleague succeeds in difficult project or the architecture comes together.

To us, who have experienced dozens of projects and clients, we tend to know the direction for the chills for success.

Meaning, we have created models from the past experiences. These models are formal structures explaining the world around.

The models

If we master and understand the models, it improves our communication, enables us to explain difficult scenarios, reason and cooperate with our teammates, predict the outcome from a solution and furthermore explore different options.

When our thinking is logical, consistent and based on past experiences, we are more likely to make wise choices. No matter if we speak about development team trying to implement difficult business case or just us cooking for our family.

The same is true, when a salesperson tries to find out what a customer truly needs or when we are implementing the next cloud-enabled solution for the customer.

Building value

It is all about building value. Is the food you prepare the value or is it merely a tool for you to have energy to play with your children?

Nevertheless I’m sure each and everyone of us have made up models, how to build value and get the chills in different situations.

Good architecture and implementation is crucial, but we should not forget to put the customer to the spotlight.

Do we have a solid business case and most important where is the value? We should not ask what  the customer wants, but what the customer needs.

Try 3 whys the next time you’re thinking of making a big decision:

“Why we are building the infrastructure to the cloud?”

“We need to grow our capacity and we need to be highly available and resilient”

“Why it is important to improve scalability and resilience?”

“The old infrastructure can not handle the increased traffic”

“Why the old infrastructure is not enough anymore?”

“We have analysed the platform usage. If we get more capacity on the rush hours, we can serve more customers.”

Productise

All right! We are convinced the customer needs the cloud migration and start working with the implementation.

Solita has productised the whole cloud journey, so we can quickly get into speed.

Ready made instructions, battle proven implementations and peer-support from earlier projects will help you up to speed.

Technical solutions follow a model, meaning there are few ways to provision a database, few ways to do networking in the cloud, few ways to optimize expenditure.

When we do not plan and develop everything from scratch, we build value.

Re-use

According to study published in the book Accelerate: The Science of Lean Software and DevOps, to be productive, everything should be in version control.

For sure the application code is already in the version control, but also system configuration, application configuration and scripts for automated build, test and delivery should be in version control.

The study revealed, keeping configurations and scripts in the version control correlated more to the software delivery performance than keeping the application code in the version control.

When building for cloud, the infrastructure must be defined in code. And the code should reside.. in version control!

This enables us to move faster without trade offs. We can recognise modules, implement them once, create automated tests and then re-use the codebase in customer repositories.

Every time we are able to do this, we build value.

Automate

Humans are erroneous. This is an experience based model. When computers handle the repetitive work, it enables people to solve problems.

We know from experience, automation requires investments and should be implemented from day one. Investments done here will result smaller development lead time, easier deployments and more quality code.

In cloud, we describe our infrastructure as code. This goes hand in hand with automation. Based on this model, we choose to automate recurring tasks such as building code, testing and making the deployments.

As a result we speed up the feedback loops, have repeatable results each time and enable developers make quality code and automated tests. We test our infrastructure in the pipeline and once again build value.

Deliver

Deliver continuously in small chunks is an experience based model.

You most surely want to have your piece of code tested and delivered to production before you forget, what you were doing.

Short lived branches or Trunk-Based Development predict performance. Failures in small changes are far easier to fix.

Also test automation is key part of continuous delivery. Reliable automated tests predict performance and improves quality. Diagram below is from the book Accelerate. 

High Performers who had adopted the Continuous Delivery model spent far more time on new work than in unplanned or rework.

Although unplanned, emergency and refactoring work is a necessity, value is built when implementing new features.

Software Delivery Performance

Measuring software delivery performance is difficult. An incorrect productivity metric can easily lead to poor decisions.

If you want to deliver the feature as quickly as possible without trading for quality, one key metric is development Lead Time. This is because code not in production is a waste.

For example Software Delivery Performance can be split to 4 topics:

  • Lead Time (from starting implementation to delivery to production)
  • Deployment Frequency (more often results smaller changes)
  • Mean Time to Restore (how to recover from failure)
  • Change Failure Rate (how often the changes cause a failure)

According to the study made by the authors of the book Accelerate, these are the measures from different types of Organisations:

Conclusion

Past experiences makes us what we are. Stop and think the models you have crafted. Challenge yourself, interact with your peers, find out new models for building value.

Together with the team and with the customer, you’ll will find the best solution for the opportunity at hand. Remember the actual implementation is only a fraction of the whole journey.

On pure technical aspect, we should re-use as much as possible and we should automate as much as possible. When talking about cloud migration, infrastructure must be described as code (IaC).

Does your organisation understand and use the models?

Does your organisation productise and re-use the codebase?

Let’s build value!

 

Avoid the pitfalls: what to keep in mind for a smooth start with cloud services

Many companies are looking for ways to migrate their data centre to the cloud platform. How to avoid potential pitfalls in migrating data centres to the public cloud? How to plan your migration so that you are satisfied with the end result and achieve the set goals?

Why the public cloud?

The public cloud provides the ability to scale as needed, to use a variety of convenient SAAS (Software as a Service), PAAS (Platform as a Service) and IAAS (Infrastructure as a Service) solutions, and to pay for the service exactly as much as you use it.

 The public cloud gives a company the opportunity for a great leap in development, the opportunity to use various services of a service provider during development, as those accelerate the development and help create new functionality.

 All of this can be conveniently used without having to house a personal data centre.

Goal setting

The first and most important step is to set a goal for the enterprise. The goal cannot be general; it must be specific and, if possible, measurable, so that it would be possible to assess at the end of the migration whether the set goal has been achieved or not.

Goal setting must take the form of internal collaboration between the business side and the technical side of the company. If excluding even one party, it is very difficult to reach a satisfactory outcome.

The goals can be, for example, the following:

  • Cost savings. Do you find that running your own data centre is too expensive and operating costs are very high? Calculate the cost, how much resource the company will spend on it, and set a goal of what percentage in savings you want to achieve. However, cost savings are not recommended as the main goal. Cloud providers also aim to make a profit. Rather, look for goals in the following areas to help you work more efficiently.
  • Agility, i.e. faster development of new functionalities and the opportunity to enter new markets.
  • Introduction of new technologies (ML or Machine Learning, IOT or Internet of Things, AI or Artificial Intelligence). The cloud offers a number of already developed services that have been made very easy to integrate.
  • End of life for hardware or software. Many companies are considering migrating to the cloud at the moment when their hardware or software is about to reach its end of life.
  • Security. Data security is a very important issue and it is becoming increasingly important. Cloud providers invest heavily in security. Security is a top priority for cloud providers because an insecure service compromises customer data and thus they are reluctant to buy the service.

The main reason for migration failure is the lack of a clear goal (the goal is not measurable or not completely thought out)

Mapping the architecture

The second step should be to map the services and application architecture in use. This mapping is essential to choose the right migration strategy.

In broad strokes, applications fall into two categories: applications that are easy to migrate and applications that require a more sophisticated solution. Let’s take, for example, a situation where a large monolithic application is used, the high availability of which is ensured by a Unix cluster. An application with this type of architecture is difficult to migrate to the cloud and it may not provide the desired solution.

The situation is similar with security. Although security is very important in general, it is especially important in situations where sensitive personal data of users, credit card data, etc. must be stored and processed. Cloud platforms offer great security solutions and tips on how to run your application securely in the cloud.

Security is critical to AWS, Azure, and GCP, and their security is invested into much more than individual customers could ever do.

Secure data handling requires prior experience. Therefore, I recommend migrating applications with sensitive personal data at a later stage of the migration, where experience has been gained. It is also recommended to use the help of different partners. Solita has previous experience in managing sensitive data in the cloud and is able to ensure the future security of data as well. Partners are able to give advice and draw attention to small details that may not be evident due to lack of previous experience.

This is why it is necessary to map the architecture and to understand what types of applications are used in the companies. An accurate understanding of the application architecture will help you choose the right migration method.

Migration strategies

‘Lift and Shift’ is the easiest way, transferring an application from one environment to another without major changes to code and architecture.

Advantages of the ‘Lift and Shift’ way:

  • In terms of labour, this type of migration is the cheapest and fastest.
  • It is possible to quickly release the resource used.
  • You can quickly fulfil your business goal – to migrate to the cloud.

 Disadvantages of the ‘Lift and Shift’ way:

  • There is no opportunity to use the capabilities of the cloud, such as scalability.
  • It is difficult to achieve financial gain on infrastructure.
  • Adding new functionalities is a bit tricky.
  • Almost 75% of migrations take place again within two years. Either they go back to their data centre or they use another migration method. At first glance, it seems like a simple and fast migration strategy, but in the long run, it will not open up the cloud’s opportunities and no efficiency gains will be achieved.

‘Re-Platform’ is a way to migrate where a number of changes are made to the application that enable the use of services provided by the cloud service provider, such as using the AWS Aurora database.

Benefits:

  • It is possible to achieve long-term financial gain.
  • It can be scaled as needed.
  • You can use a service, the reliability of which is the service provider’s responsibility.

 Possible shortcomings:

  • Migration takes longer than, for example, with the ‘Lift and Shift’ method.
  • The volume of migration can increase rapidly due to the relatively large changes made to the code.

‘Re-Architect’ is the most labour- and cost-intensive way to migrate, but the most cost-effective in the long run. During the re-architecture, the application code is changed sufficiently that it can be handled smoothly in the cloud. This means that the application architecture will take advantage of the opportunities and benefits offered by the cloud

Advantages:

  • Long-term cost savings.
  • It is possible to create a highly manageable and scalable application.
  • An application based on the cloud and micro services architecture enables to add new functionality and to modify the current one.

Disadvantages:

  • It takes more time and therefore more money for the development and migration.

Start with the goal!

Successful migration starts with setting and defining a clear goal to be achieved. Once the goals have been defined and the architecture has been thoroughly mapped, it is easy to offer a suitable option from those listed above: either ‘Lift and Shift’, ‘Re-Platform’ or ‘Re-Architect’.

Each strategy has its advantages and disadvantages. To establish a clear and objective plan, it is recommended to use the help of a reliable partner with previous experience and knowledge of migrating applications to the cloud.

Turbulent times in security

We are currently living very turbulent times: COVID-19 is still among us, and at the same time we are facing a geopolitical crisis in Europe not seen since the second world war. You can and you should prepare for the changed circumstances by getting the basics in order.

On top of the normal actors looking for financial gains, state-backed actors are now likely to activate their campaigns against services critical for society. This expands beyond the crisis zone, we have for example already seen Denial of Service attacks against banks. It is likely that different types of ransomware campaigns and data wipers will also be seen in western countries targeting utilities providers, telecommunications, media, transportation and financial institutions and their supply chains.

So what should be done differently during these times in terms of securing our business and environments? Often an old trick is better than a bagful of new ones, meaning that getting the basics right should always be the starting point. There’s no shortcuts in securing the systems, there’s no single magic box that can be deployed to fix everything.

Business continuity and recovery plans

Make sure you have the business continuity plan and recovery plan available and revised. Also require the recovery plans from your service providers. Make sure that roles and responsibilities are clearly defined and everyone knows the decision making tree. Check that the contact information is up to date, and your service providers and partners have your contact information correct. It is also a good idea to practice cyberattack scenarios with your internal and external stakeholders to see potential pitfalls of your plan in advance.

Know what you have out there!

How certain are you that the CMDB you have is 100% up-to-date? When’s the last time you have checked how your DNS records have been configured? Do you really know what services are visible to the internet? Are you aware what software and versions you are using in your public services? These questions are the same what malicious actors are going through when they are gathering information on where to attack and how. This information is available on the internet for everyone to find out, and this is something that all organizations should also use for their own protection. There are tools and services (such as Solita WhiteHat) available to perform reconnaissance checks against your environment. Use them or get a partner to help you in this.

Keep your software and systems updated

This is something that everyone of us hears over and over again, but still: It is utmost important to keep the software up-to-date! Every single software contains vulnerabilities and bugs which can be exploited. Vendors are nowadays patching vulnerabilities coming to their attention rather quickly, so use that as your own benefit and apply the patches.

Require MultiFactor Authentication and support strong passwords

This one is also on every recommendation list and it’s not there for nothing. Almost all services nowadays provide the possibility to enable MFA, so why not to require it. It is easy to set up and provides an additional layer of security for users, preventing brute forcing and password spraying. It doesn’t replace a good and strong password, so a rather small thing to help users in creating strong passwords and prevent using same passwords in multiple services is to provide them a password manager software, such as LastPass or 1Password. If you have SSO service in place, make sure you take the most out of it.

Take backups and exercise recovery

Make sure you are backing up your data and services. Also make sure that backups are stored somewhere else than in the production environment, to prevent for example ransom trojans making them useless. Of course, just taking backups is not enough, but the recovery should be tested periodically (at least yearly) to make sure that when recovery is needed it will actually work.

What if you get hit

One famous CEO once said that there are two types of companies: ones that have been hacked and ones who don’t know they have been hacked. So what should you do if you even suspect that you have been attacked:

Notify authorities

National authorities run CERT (Computer Emergency Response Team) teams, who maintain the situational awareness and coordinate the response actions on national level. For example in Finland its kyberturvallisuuskeskus.fi and in Sweden cert.se.  So if you suspect a possible data leak or attack, notify the local CERT and at the same time, file a police report. It is also advisable to contact a service provider who can help you to investigate and mitigate the situation. One good source to find a service provider providing Digital Forensics and Incident Response services is from dfir.fi.

Isolate breached targets and change/lock credentials

When you suspect a breach, isolate the suspected targets from the environment. If possible cut off network access and let the resources still run, this way you are not destroying possible evidence by turning off the services (shutting down servers, deleting cloud resources).  At the same time, lock the credentials suspected to be used in the breach and change all the passwords.

Verify logs

Check that you have logs available from the potentially breached systems. Best case would be that the logs are available outside of the system in question. If not, back them up to external storage, to make sure that it doesn’t get altered or removed by the attacker.

Remember to communicate

Communicate with stakeholders, remember your users, customers and public. Although it may feel challenging to tell these kinds of news, it’s much better to be open in the early stages than to get caught your pants down later on.

To summarise

The threat level is definitely higher due to above mentioned circumstances, but getting the basics in order helps you to react if something happens. Keep also in mind that you don’t have to cope in this situation alone. Security service providers have the means and capacity to support you in efficient way. Our teams are always willing to help to keep your business and operations secure.

 

Very Large Array, Socorro, United States

Alerting Estonian Citizens with Azure

Why not take advantage of the public cloud? Read how the system for transmitting alarm messages to consumers was born in Estonia. With this piece of writing, we go through one specific and technical real-life journey from the birth of an idea to its implementation in the Microsoft Azure cloud environment.

 

The author of the article works for the company Solita as a Data Engineer since 2019 and specialises in cloud-based data platforms. By now, he has accumulated more than 20 years of experience in various fields of the IT sphere – development, architecture, training. Many interesting projects have been made both in Estonia and abroad.

The beginning

In the digital state’s Hackathon event, Solita addressed the transmission of government’s cultural messages to televisions via an Android app.

In parallel, the Ministry of the Interior’s IT Centre (SMIT) pointed out a similar need. Sending alarm messages from the SITREP (Situation Reporting) system to the mobile application ‘Ole valmis!’ (‘Be ready!’) was considered. The purpose of that application became to warn the user of a nearby accident or deteriorating weather (such as a snowstorm, or a coastal flood).

In conclusion, since the pattern was the same, it seemed reasonable to create a single, unified solution.

Problems and objectives

SITREP did not have a public interface for requesting messages, but it did have the functionality to send messages. So it was possible to interface the system directly with the back-end of the ‘Ole valmis!’ (‘Be ready!’) application. The following goals emerged in the process of the Hackathon, which led to the development of a separate cloud-based system.

  • Transmission of messages (push and pull) must be possible to several channels in parallel, whoever the consumer is.
  • The messaging functionality must be separate from SITREP.
  • The interface must be secure so that a malicious actor cannot send false alarms.
  • It must be easy to administer.
  • It must be possible to subscribe / categorise messages by subject and location.
  • Setting up the system must be quick and easy.
  • The system must be flexible and inexpensive to maintain.
  • The available development time is a couple of man-months.

Why Microsoft Azure?

Solita participated in the Hackathon in partnership with Microsoft, which is why Azure was chosen as the cloud environment – although similar solutions could be created with the help of AWS or Google, for example. Azure also provides some direct benefits.

  • Most components can be easily integrated with Active Directory (although Active Directory was not an end in itself in the first iteration, this was one argument to consider in the future).
  • The range of services (in other words – the arsenal of ‘building blocks’ of the completed system) is really impressive and also includes exclusive components – in the following we will take a closer look at some of them.

For example, API Management is, to put it simply, a scalable API gateway service, and as a big bonus, it includes a public Web portal (Developer Portal) that is convenient for both the user and the administrator. In addition, the interface can be redesigned to suit your needs. The main value comes precisely from the ease of use – you don’t have to have much Azure-specific knowledge to sign up, send / receive messages, set the final destination, describe conversion rules.

The Developer Portal provides developers with pre-written sample code for consuming messages (presented in cURL, C#, and Python, for example). In addition, of course, a built-in firewall, resilience, and resistance to DDoS-type attacks are provided. All of the above saves a lot of time (and money!) from the user’s, administrator’s and developer’s point of view.

Infrastructure creation process

From the architect’s point of view, the aim was to create a system based on the most standard possible components (provided by Azure itself), and the installation of which would be simple enough for anyone with a basic knowledge of the working principle of the cloud. Account had also to be taken of the fact that the requirements were also still evolving.

From the beginning, we relied on the principle of IaC (Infrastructure as Code) – the entire infrastructure of the solution in the cloud is unambiguously described as human and machine readable code. In addition, the installation process would be incremental (if a new version is created, the existing infrastructure could be updated instead of recreating), configurable and automated; the code would be as clear and editable as possible. Figuratively speaking, you press ‘deploy’ and you don’t need much else.

All of the above is made possible by a tool called Terraform, which is quite common, especially among those who administer infrastructures – so-to-speak the de-facto standard for precisely cloud infrastructures. It is a free tool produced by HashiCorp that is perfect for situations like this – a person describes in a code what resources he needs, and Terraform interprets the code into instructions that can be understood by the (cloud) environment to create, modify or delete them.

Terraform has the following strengths that were the decisive factor:

  • its spread and wide platform support,
  • the ability to ‘remember’ the state of the installed infrastructure,
  • the simple but powerful HCL language that can be used to describe even complex logic.

The method officially supported by Microsoft for achieving the same are ARM templates (ARM templates are essentially structured static JSON or YAML). The entire Azure infrastructure can be described based on purely ARM templates, but then more code is created and the possibilities of directing the installation logic are greatly reduced.

Changing requirements and options

The first thing that the work continued on was creating a message store (for pull scenario and debugging).

The initial understanding of the message format was quite simple:

  • single-level JSON,
  • a few required attributes (timestamp, author, etc.),
  • rest of the schema was completely open.

Based on the above and on the principled decision to use only Microsoft Azure components + to install the entire solution with a single command, two options remained on the table for storing and reading JSON data without a defined schema:

  • Table Storage (default; although by operating principle it is a key / attribute type service),
  • Cosmos DB.

The ability to query data via HTTP(S) (less development work) and a lower cost (especially important in the prototype phase) spoke in favour of Table Storage; Cosmos DB had the advantage of storage flexibility, as it stores data in several regions. However, the situation was changed by the fact that SITREP’s messages came as a multi-level JSON and some of the critical attributes were at a ‘deeper’ level. Therefore, Table Storage no longer met the new requirement and the Cosmos DB component had to be introduced instead.

In addition, there was a real possibility that the system would be used in a context other than alarm messages – it had to be taken into account that the system could be used for transmitting virtually any message from many senders to different channels in different combinations. In essence, the goal became to create a messaging platform (Message Service Provider) that would functionally resemble the products of Twilio or MessageBird, for example.

Not a single line of ‘real’ code

So, by now, the following was architecturally in place:

  • all incoming messages and queries went through API Management,
  • all messages were stored in the Cosmos DB database.

 

At the same time, pushing messages to destinations through API Management remained an open issue. And exactly which component handles the database of messages and destination addresses?

Microsoft Azure offers options for almost any scenario, from an application hosted on a virtual machine to a serverless component called Azure Function. You can also use a number of intermediate variants (Docker, Kubernetes, Web App), where the user may or may not have direct access to the server hosting the application.

In the context of the present solution, all the above solutions would have meant the following:

  • a person with a developer background would have been needed to create the system,
  • the system as a whole could no longer be installed very easily – the application code would have been separate from the infrastructure code.

Fortunately, Azure has provided the Logic App technology that addresses the above issues. It’s a way to describe business logic as a flowchart – for example, you can visually ‘draw’ a ready-made Logic App ‘application’ in the Azure Portal, using the online interface.

It is true that in more complex cases, such as conversion operations, you will probably need to write a few lines of code, but this is far from traditional programming. Writing Logic App code is more akin to developing Excel macros than Python or Java.

The Logic App flow code can be saved as an ARM template, and the ARM template can be used as part of a Terraform installation script – making the Logic App a great fit for this context. Starting a single workflow in this solution costs in the order of 0.0005 euros per occasion (according to the consumption-based plan) – yes, there are even cheaper solutions like Azure Function, but in this case the infrastructure needs to be installed and developed separately.

Support components

Azure has well-thought-out tools for monitoring the operation of the system; in this case we focus on two of them: Azure Monitor and Log Analytics. The first, as the name suggests, is a set of dashboards provided by the Azure platform that help monitor the status of applications and components (including in real-time), such as load, memory usage, and user-defined metrics.

Since the Monitor is ‘included’ with every solution by default, it may not be correct to consider it as a separate component – it is simply a question of displayed indicators. Log Analytics, on the other hand, is a place to direct the logs of all components so that they can be conveniently analysed and queried later. This helps detect system errors and quickly track down errors. You can even query Log Analytics for metrics to display later in the Monitor, such as the number of errors per day.

Results and observations

In summary, the architecture of the solution came out as follows.

Messaging system architecture in Azure
Messaging system architecture in Azure

 

Broadly, the objectives set out at the start were achieved and the principles were followed (IaC, Azure components only, etc.). Clearly, Microsoft Azure offers a truly comprehensive suite of services with typically 99.95-99.99% SLAs; however, ‘the seven nines’ (99.99999%) or even higher are not uncommon. Such a high percentage is achieved through redundancy of components and data, optimised hardware usage, and exceptionally strict security measures in the region’s data centres.

Installing a system from scratch on an Azure account takes 45-60 minutes, and the lion’s share of this is provisioning API Management – a kind of heavyweight in Microsoft Azure, with a number of internal components hidden from the user (firewall, web server, load balancer, etc.).

There were no obstacles, but the development revealed that Terraform is a few steps behind Microsoft Azure as a third-party tool – in other words, when Microsoft launches a new Azure service, it will take time for HashiCorp developers to add functionality to their module. In this case, for example, the ARM template for the new component can be partially grafted into Terraform scripts, so that the creation of the infrastructure can be automated in any case.

In conclusion

Public cloud providers, such as Microsoft Azure, have hundreds of different services that can be considered Lego blocks – combining services to create the solution that best meets your needs.

The article describes how an MSP-like product was created from scratch that has reached the pre-live status by now. The same product can be assembled from different components – it all depends on the exact needs and on the possibilities to include other competencies, such as C# or Java developer’s. The public cloud is diverse, secure, affordable and ever evolving – there are very few reasons not to take advantage of it.

Thank you: Janek Rozov (SMIT), Timmo Tammemäe (SMIT), Märt Reose (SMIT), Kristjan Kolbre (‘Ole valmis!’), Madis Alesmaa (‘Ole valmis!’), Elisa Jakson (Women’s Voluntary Defence Organisation / ‘Ole valmis!’), Henrik Veenpere (Rescue Board).

Cloud services

Hybrid Cloud Trends and Use Cases

Let's look at different types of cloud services and learn more about the hybrid cloud and how this cloud service model can exist at an organisation. We’ll also try to predict the future a bit and talk about what hybrid cloud trends we are expecting.

As an IT person, I dare say that today we use the cloud without even thinking about it. All kinds of data repositories, social networks, streaming services, media portals – they work thanks to cloud solutions. The cloud now plays an important role in how people interact with technology.

Cloud service providers are inventing more and more features and functionalities, bringing them to the IT market. Such innovative technologies offer even more opportunities for organisations to run a business. For example, AWS, one of the largest providers of public cloud services, announces over 100 product or service updates each year.

Cloud services

Cloud technologies are of interest to customers due to their economy, flexibility, performance and reliability.

For IT people, one of the most exciting aspects of using cloud services is the speed at which the cloud provides access to a resource or service. A few clicks at a cloud provider’s portal – and you have a server with a multi-core processor and large storage capacity at your disposal. Or a few commands on the service provider’s command line tool – and you have a powerful database ready to use.

Cloud deployment models

In terms of the cloud deployment model, we can identify three main models:

• A public cloud – The service provider has publicly available cloud applications, machines, databases, storage, and other resources. All this wealth runs on the IT infrastructure of the public cloud service provider, who manages it. The best-known players in the public cloud business are AWS, Microsoft Azure and Google Cloud.

In my opinion, one of the most pleasant features of a public cloud is its flexibility. We often refer to it as elasticity. An organisation can embark on its public cloud journey with low resources and low start costs, according to current requirements. 

Major public cloud players offer services globally. We can easily launch cloud resources in a geographical manner which best fits our customer market reach. 

For example, in a globally deployed public cloud environment, an organization can serve its South American customers from a South American data centre. A data centre located in one of the European countries would serve European customers. This greatly improves the latency and customer satisfaction.

There is no need to invest heavily in hardware, licensing, etc. – organisation spends money over time and only on the resources actually used.

• A private cloud – This is an infrastructure for a single organisation, managed by the organisation itself or by a service provider. The infrastructure can be located in the company’s data centre or elsewhere.

The definition of a private cloud usually includes the IT infrastructure of the organisation’s own data centre. Most of these state-of-the-art on-premise solutions are built using virtualisation software. They offer the flexibility and management capabilities of a cloud.

Here, however, we should keep in mind that the capacity of a data centre is not unlimited. At the same time, the private cloud allows an organisation to implement its own standards for data security. It also allows to follow regulations where applicable. Also, to store data in a suitable geographical area in its data centre, to achieve an ultra low latency, for example. 

As usual, everything good comes with trade-offs. Think how complex activity it might be to expand the private cloud into a new region, or even a new continent. Hardware, connectivity, staffing, etc – organisation needs to take care of all this in a new operating area. 

• A hybrid cloud – an organisation uses both its data centre IT infrastructure (or its own private cloud) and a public cloud service. Private cloud and public cloud infrastructures are separate but interconnected.

Using this combination, an organisation can store sensitive customer data in an on-premise application according to regulation in a private cloud. At the same time, it can integrate this data with corporate business analytics software that runs in a public cloud. The hybrid cloud allows us to use the strengths of both cloud deployment models.

Hybrid cloud model

When is a hybrid cloud useful?

Before we dive into the talk about hybrid cloud, I’d like to stress that we at Solita are devoted advocates of cloud-first strategy, referring to public cloud. At the same time, cloud-first does not mean cloud-only, and we recognize that there might be use-cases when running a hybrid model is justified, be it regulation reasons or very low latency requirements.

Let’s look at some examples of when and how a hybrid cloud model can benefit an organisation. 

Extra power from the cloud

Suppose that the company has not yet made its migration to public cloud. Reasons can be lack of resources or cloud competence. It is running its private cloud in a colocation data centre. The private cloud is operating at a satisfactional level while the load and resource demand remains stable. 

However, the company’s private cloud lacks extra computing resources to handle future events of demand growth. But an increased load on the IT systems is expected due to an upcoming temporary marketing campaign. As a result of the campaign, the number of visitors to the organisation’s public systems will increase significantly. How to address this concern?

The traditional on-premise way used to be getting extra resources in the form of additional hardware. It means new servers, larger storage arrays, more powerful network devices, and so on. This causes additional capital investment, but it is also important that this addition of resources may not be fast.

The organisation must deliver, install, configure the equipment – and these jobs cannot always be automated to save time. After the load on the IT systems has decreased with the end of the marketing campaign, the situation may arise that the acquired additional computing power is not used any more.

But given the capabilities of the cloud, a better solution is to get additional resources from the public cloud. Public cloud allows to do this flexibly and on-demand, as much as the situation requires. The company spends and pays for resources only as it needs them, without large monetary commitments. Let the cloud adoption start 😊

The organisation can access additional resources from the public cloud in hours or even minutes. We can order these programmatically, and in automated fashion in advance, according to the time of the marketing campaign.

When the time comes and there are many more visitors, the company will still keep the availability of its IT systems. They will continue to operate at the required level with the help of additional resources. This method of use is known as cloud bursting, i.e. resources “flow over” to another cloud environment.

This is the moment when a cloud journey begins for the organization. It is an extremely important point of time when the organization must carefully evaluate its cloud competence. It needs to consider possible pitfalls on the road to cloud adoption. 

For an organisation, it is often effective to find a good partner to assist with cloud migration. The partner with verified cloud competence will help to get onto cloud adoption rails and go further with cloud migration. My colleagues at Solita have written a great blog post about cloud migration and how to do it right.

High availability and recovery

Implementing high availability in your data centre and/or private cloud can be expensive. As a rule, high availability means that everything must be duplicated – machines, disk arrays, network equipment, power supply, etc. This can also mean double costs.

An additional requirement can be to ensure geo-redundancy of the data and have a copy in another data centre. In such case, the cost of using another data centre will be added.

A good data recovery plan still requires a geographically duplicated recovery site to minimise risk. From the recovery site, a company can quickly get its IT systems back up and running in the event of a major disaster in a major data centre. Is there a good solution to this challenge? Yes, there is.

A hybrid cloud simplifies the implementation of a high availability and recovery plan at a lower cost. As in the previous scenario described above, this is often a good starting point for an organisation’s cloud adoption. Good rule of thumb is to start small, and expand your public cloud presence in controlled steps.

A warm disaster recovery site in the public cloud allows us to use cloud resources sparingly and without capital investment. Data is replicated from the main data centre and stored in the public cloud, but bulky computing resources (servers, databases, etc.) are turned off and do not incur costs.

In an emergency case, when the main data centre is down, the resources on the warm disaster recovery site turn on quickly – either automatically or at the administrator’s command. Because data already exists on the replacement site, such switching is relatively quick and the IT systems have minimal downtime.

Once there is enough cloud competence on board, the organisation will move towards cloud-first strategy. Eventually it would switch its public cloud recovery site to be a primary site, whereas recovery site would move to an on-premise environment.

Hybrid cloud past and present

For several years, the public cloud was advertised as a one-way ticket. Many assumed that organisations would either move all their IT systems to the cloud or continue in their own data centres as they were. It was like there was no other choice, as we could read a few years ago.

As we have seen since then, this paradigm has now changed. It’s remarkable that even the big cloud players AWS and Microsoft Azure don’t rule out the need for a customer to design their IT infrastructure as a hybrid cloud.

Hybrid cloud adoption

Organisations have good reasons why they cannot always move everything to a public cloud. Reasons might include an investment in the existing IT infrastructure, some legal reasons, technical challenges, or something else.

Service providers are now rather favouring the use of a hybrid cloud deployment model. They are trying to make it as convenient as possible for the customer to adopt it. According to the “RightScale 2020 State of the Cloud” report published in 2020, hybrid cloud is actually the dominant cloud strategy for large enterprises:

Hybrid cloud is the dominant strategy

Back in 2019, only 58% of respondents preferred the hybrid cloud as their main strategy. There is a clear signal that the hybrid cloud offers the strengths of several deployment models to organisations. And companies are well aware of the benefits.

Cloud vendors vs Hybrid

How do major service providers operate on the hybrid cloud front? Microsoft Azure came out with Azure Stack – a service that is figuratively speaking a public cloud experience in the organisation’s own data centre.

Developers can write the same cloud native code. It runs in the same way both in a public Azure cloud and in a “small copy” of Azure in the enterprise’s data centre. It gives the real cloud feeling, like a modern extension to a good old house that got small for the family.

Speaking of multi-cloud strategy as mentioned in the above image, Azure Arc product by Microsoft is worth mentioning, as it is designed especially for managing multi-cloud environments and gaining consistency across multiple cloud services.

AWS advertises its hybrid cloud offering portfolio with the message that they understand that not all applications can run in the cloud – some must reside on customers premises, in their machines, or in a specific physical location.

A recent example of hybrid cloud thinking is AWS’s announcement of launching its new service ECS Anywhere. It’s a service that allows customers to run and manage their containers right on their own hardware, in any environment, while taking advantage of all the ECS capabilities that AWS offers in the “real” cloud to operate and monitor the containers. Among other things, it supports “bare” physical hardware and Raspberry Pi. 😊

As we’ve also seen just recently, the next step for Amazon to win hybrid cloud users was the launch of EKS Anywhere – this allows customers using Kubernetes to enjoy the convenience of a managed AWS EKS service while keeping their containers and data in their own environment, on their own data centre’s machines.

As we see, public cloud vendors are trying hard with their hybrid service offerings. It’s possible that after a critical threshold of hybrid services users is reached, it will create the next big wave of cloud adoption in the next few years. 

Hybrid cloud trends

The use of hybrid cloud related services mentioned above assumes that there is cloud competence in the organisation. These services integrate tightly with the public cloud. It is important to have skills to manage these correctly in a cloud-native way.

I think we will see a general trend in the near future that the hybrid cloud will remain. Multi-cloud strategy as a whole will grow even bigger. Service providers will assist customers in deploying a hybrid cloud while maintaining a “cloud native” ecosystem. So that the customer has the same approach to developing and operating their IT systems. It will not matter whether the IT system runs in a “real” cloud or on a hybrid model. 

The convergence of public, private and hybrid models will evolve, whereas public cloud will continue to lead in the cloud-first festival. Cloud competence and skills around it will become more and more important. The modern infrastructure will not be achievable anymore without leveraging the public cloud.

Growing from a small cloud team to a community of over 70 people

The cloud community at Solita has grown substantially in the past years. While the industry has been developing rapidly, we've done our best to stay ahead of the game. Our recipe for growth has two main ingredients: a sensitive ear to our clients’ evolving needs and a clear vision to build a caring work culture where people can excel in their jobs.

We are long-term solitans, and we’ve had the opportunity to witness the growth of our cloud community from the start. The team was created when we saw the first signs from our clients that there is a need for cloud specialization. In the beginning, in 2014, we only had a couple of people in the team. But we had our eyes in the market, and we started developing our cloud services from a holistic point of view. We wanted to be a full-service cloud partner and kept this in mind when planning and developing our services.

In 2016 when we saw an increased number of opportunities in the market, we officially launched our Cloud & Connectivity unit. Since then, we have grown from a small team to a community of over 70 cloud professionals. These people are specialized in demanding cloud services, like infrastructure, cyber security, and public cloud platforms.

It all started from our clients’ needs 

The key driver in our growth has been the willingness to serve our clients better and pay close attention to their needs. When we saw a growing demand, we responded to it. In the past years, the world has turned more complex, and technologies have developed very fast. These days a big part of our job is to help our clients to choose the right solutions that serve their needs in the best possible way.

It’s also been an interesting journey to see how the attitudes towards cloud services have evolved. There was a lot of resistance and insecurity in the beginning. These days it’s quite the opposite. Our client portfolio has become diverse, including organizations from many different industries. We also work with several organizations in the public sector, and we’ve built cloud solutions for companies in the heavily regulated financial sector. Cloud has become mainstream, and we’ve been glad to be part of this development.

As an example, we’ve helped Savings Bank build a solid cloud foundation and supported them with their “cloud first” strategy, which states that as much as possible should be built on the public cloud. Solita CloudBlox has allowed them to get up and running quickly, and results so far have been great. As for billing and reporting, the contrast between the transparency of Solita CloudBlox and the traditional data center world could not be greater. For the first time ever, Savings Bank gets thoroughly granular reports on every hour worked, every euro spent, and every cloud component implemented – literally, an eye-opener for the bank.

Our people have enabled our growth

Solita is a value-driven and people-focused company, and our people play a key role in our growth equation. While managing growth is not always easy, during every step, we’ve tried to do our best to make sure that people are happy to work here. We have fostered our culture and kept the organization lean and agile.

In practice, it means that our people have a voice, and their opinions are appreciated. Our professionals get plenty of freedom to execute their work the best way they think they should, and everyone gets to have a say in which type of projects they want to work. Caring is one of our core values, and it’s visible in many ways. Our people here really care for one another. There is always help and support available; you are never left alone.

Cloud&Connectivity Day at the Biitsi 2021 / Nea Tamminen

But being a frontrunner company in many arenas also means that there

is a requirement to learn new things, explore and test new products, and investigate new services. For some, it could become overwhelming or uncomfortable. Also, the fact that we deliver a wide range of projects means that people must be adaptable, and managing oneself becomes essential. We live in a constant change in this industry, so we need to stay alert and aim to be a bit ahead of the game all the time. And it’s our job as leaders to provide the best possible set-up for our people to do so.

The growth in the cloud community has also provided a personal growth journey for both of us. We’ve understood that like this community, also we personally are constantly evolving and never “ready”. We’ve gone through tough moments as well, but when we’ve had the courage and humility to ask for help, there’s been a line of colleagues providing their support. That’s the beauty of our culture and something we also want to hold on to in the future.

Writers of this blog, Jari Jolula and Karri Lehtinen, are long-term Solitans and have been leading our Cloud offering since the beginning.

Would you have something to add in our culture? Please check our openings and contact us!

Want to know how we do managed cloud? Please visit our Solita CloudBlox site.