Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. (Part 3) — Second half

This article is the third of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. We received a contribution from Mr. Yasuo Matsuura, an executive officer. The introduction will be divided into 2 parts: the first half and the second half. This article is the second half of that.

The following articles have also been published as serialized articles, so please be sure to check them out.

4. Key points of cloud utilization

As introduced in the third chapter of the second blog in this series, the philosophy for our cloud-based smart meter relies on three main factors: flexible scalability through loosely-coupled architectures, realizing a high level of availability in our system, and having agility through our use of managed services.

In order to maximize the benefits of the cloud (including TCO reduction) to the best of our ability, we’ve found that it is important to proceed development with the optimal combination of AWS services. However, AWS provides a wide variety of services which each have different features and usages, so it’s essential to master AWS’s full offerings so that you can match them to your own requirements along with correctly implementing appropriate security measures such as data protection and access control.

Based on this approach, I think the following three points are particularly important when developing on the AWS cloud:

First, properly understanding system and cloud architectures ourselves, as end-users
Also making sure that your vendors correctly understand the cloud, embrace it, and have the proper workflow in place to implement it
Finally, continuously making efforts to acquire new skills while improving your existing ones together as both end-users and vendors

In other words, having the will to properly use the cloud is essential, but you can’t successfully use the cloud by will alone. After all, you have to select the appropriate system vendors that will actively accompany your company throughout your cloud journey, and make sure that they proceed with the development of your system while closely collaborating with your business.

4-1. Correctly understanding the cloud as end-users

Looking back on the history of conventional system development, I believe that you have to correctly grasp the “big picture” of the application that you’re developing, so we are consistently making efforts to deepen our understanding of the system that we have in use from both a business and technology perspective in line with the above policy. At the same time, in order to talk about cloud, we ourselves must first understand the cloud (as we introduced in detail the fifth chapter of the second blog, Introduction of Common Infrastructure and System Control). In other words, I believe that by correctly understanding the underlying infrastructure, and by understanding it in depth, you can proceed with developing applications based on those layers and successfully cooperate with your system integrators.

I’ve sometimes heard people say things such as “there’s no need to worry about the details – we own the system!” raised as a common discussion point related to using the cloud, but as a result of our efforts so far, we believe that by correctly understanding the cloud it’s possible to enjoy many benefits beyond mere ownership of the system itself. Speaking of security aspects that are particularly easy to focus on, when using AWS, AWS itself has obtained a wide variety of security measures and certifications to guarantee them. If we want to implement these measures, I believe we need to spend time examining and trying them out for ourselves. However, at the same time, in Japan we sometimes say “let the mochi shop take care of the mochi”, or as we might say in English: “leave it to the experts.” This means leaving the actual infrastructure development, maintenance, and operation (including security) to your system vendors while you focus on the business outcomes that you originally wanted to achieve, and making sure to prepare an environment for your vendor partners so that you can ensure those outcomes together as is mentioned in the shared responsibility model.

4-2 Vendors correctly understanding the cloud

In order to properly utilize the cloud, it is very important to formulate your reasons and motives for using the cloud in the first place, such as how you’re going to tackle the overall transition to the cloud, your policies around the shift, and very importantly – organizing what you want to communicate to your system vendors. For example, if your messaging on what you want is unclear from the get-go, you might end up with a case of your servers having been simply migrated over to Amazon EC2; but in the case that your system has middleware, you of course wouldn’t be able to properly enjoy the intrinsic benefits of the cloud. In order to fully reap the cloud’s benefits, companies need to proceed with development while selecting various services and functions in the right places, such as creating a system concept that is rooted in the idea of a microservices architecture and which will make full use of AWS managed services as the building blocks of the system.

Traditionally, I feel that vendors that have developed on on-premise server environments tend to move in the direction of building more similarly conventional systems on the cloud, so if you don’t clearly show and communicate your needs and intentions as users to those vendors, I think it is common to see situations where you could hit road bumps at even the brainstorming stage. As users, it is essential to actively and comprehensively encourage vendors to understand why using the cloud is necessary in specific cases. Equally important is encouraging vendors to consider the future potential of the system from the design stage. In other words, I think a change of mind from having a sense of security and focusing purely on what advantages there are with the cloud, to actually using the cloud yourself, is an important point. Additionally, since system vendors are responsible for development, it’s clear that not only end-users but also system vendors should realize this mindset change with their customers together. Therefore, you have to select system vendors that can run side by side with your company throughout the process, as proper use of the cloud cannot be realized unless you’re cooperating and coordinating together.

As a major prerequisite for this, it is essential that the development vendor correctly understands the cloud in the first place. First, you can prevent a few problems and obstacles from occurring in system migration and operation by making sure that the systems your vendor has designed so far work correctly on the cloud, and appropriately incorporate and that cloud system’s specifications and requirements. Also, you can set yourself up for success in the long run by proceeding with a design and development philosophy that takes advantage of ideas such as microservices and serverless architecture, so that your managed services can be enjoyed to the fullest through a correct understanding of AWS services and their functions. Finally, a proper understanding of cloud security is also essential for building a robust system.

In deepening such collaborative relationships, I think it is also effective for us to have a common infrastructure as explained in the fifth chapter of the second blog, which describes organizing a collaborative system in a way that shares an environment with your vendors.

AWS Professional Services was key in their cooperation with us on this project by encouraging our vendors to make autonomous efforts, giving them technical support, and by supporting us through overall project promotion and management while constantly staying in close contact with us.

4-3. Continuously improving your cloud skills

In general, it is extremely important to adopt technologies that are compatible with cloud services (such as containers or serverless setups), but it’s also extremely important that we’re continuously learning about those technologies. If we have a goal to adopt a new technology we can achieve that goal by merely introducing it into the system, but as mentioned in the my explanation relating to common infrastructure in the fifth chapter of the second blog, brushing up your technical skills is key. It’s essential to actually understand the AWS cloud while you use it, but in most cases, acquiring a new skillset such as this tends to come down to individuals taking their own time to learn the technology. However, I believe it’s key that you motivate those involved with the project to continuously be learning themselves and make it an essential part of your organizational strategy; this is what we’re trying to do with our smart meter project and the proper use of its data moving forward.

5. Conclusion

In this blog we have introduced our smart meter system initiatives, mainly regarding our points of view and what to keep in mind in regard to how two projects with different personalities are being carried out simultaneously in parallel: a current generation system being shifted to the cloud, and the development of a next-generation system that’s cloud-native.

The decision that both systems would involve the cloud was a major decision, and as introduced in the blog, after thorough internal discussions we were finally able to establish a consensus and begin moving forward. There have of course been many in-depth discussions from both the cloud-promoting side and the more conservative side, but so far, so good although there’s been great difficulty along the way.

One additional story that I’d like to share is how we were able to exchange opinions with industry peers overseas through AWS’s introduction, and how it was interesting to hear stories of companies having had internal discussions similar to ours that still ended up with those companies adopting the cloud. I’ve always had the impression that corporations overseas are more progressive in comparison to those in Japan, but regardless of the country, I understood that companies around the world experience similar difficulty to ours when it comes to adopting the cloud, as in the end, it seems that no matter where you are there’s no such thing as a “hands off” approach to cloud migration. Also, depending on the country, we also learned that there are situations where regulators are restricting cloud use, or situations where OT systems can’t be integrated with the cloud in the first place.

Thus, of course there are still issues that arise when it comes to introducing the cloud such as navigating discussions with cautious stakeholders or the existence of regulations, etc., but as indicated in this blog, I believe from the view point of future scalability, system flexibility, and having a proper environment for proper data utilization – utilizing the cloud is essential.

I believe that in order to really use the cloud, both end users such as us and system vendors will continue to deepen our mutual understanding, and continue to refine our knowledge around the cloud. That knowledge and those skills will be continuously questioned though, with questions around what we’re aiming for and what kind of system we’re trying to introduce to accomplish that, etc, but I think the idea of a common infrastructure like with what we’ve implemented, and the account management and control that accompanies it, we’ve managed to give form to these ideas in one way. Also, regarding that philosophy, we owe a great deal to AWS, and above all, to the folks from AWS’s Professional Services team, who are truly experts among experts in the cloud space, without whom I think our activities would have easily come to a standstill.

Our project is still a work-in-progress, but I would like to take this opportunity to thank them once again. I hope this blog will help our readers think about using the cloud for future system development.

Author

This article was translated by AWS Blake Horike, Riho Matsui, and Satoshi Aoyama.

Amazon Web Services ブログ