All Things Pivotal Podcast Episode #21–Platforms vs. Platform as a Service

March 25, 2015 Coté

featured-pivotal-podcastIn this Pivotal Conversations Podcast episode (the first!), Coté talks with Andrew Shafer about “platforms” vs. “Platform as a Service.” We discuss all the operational and architectural concerns scurrying about under the tip of the iceberg known as PaaS. While we certainly offer excellent PaaS functionality, it’s just a slide of what the overall Pivotal Cloud Foundry platform provides. And what does “PaaS” mean exactly? Here, we explore what we’re talking about, exactly.

PLAY EPISODE #21

 

RESOURCES:

Transcript

Coté:
Well, hello, everybody. It’s another in our exciting conversations of what’s going on in the Pivotal space in the software development world.

Today, I’ve got Andrew Schafer on with me. How’s it going, Andrew?

Andrew Schafer:
Oh, you know. Here we are.

Coté:
Usually when you do your podcasting, it’s late at night on Sunday, and you’re doing it through YouTube with video. Do you think you’re going to be able to handle this morning podcast? You have to take some notes and see how the morning podcast goes.

Andrew Schafer:
It is 10:30 here.

Coté:
10:30 oh my God! It’s almost nighttime, right?

Andrew Schafer:
Practically after dark.

Coté:
Indeed.

We’ve been talking with analysts recently around the upcoming Pivotal Cloud Foundry release, and as you do with an analyst deck, we have the, ‘Hey, how’s it going’ part at the first, then here’s the news that’s happening in our 1.4 release of Pivotal Cloud Foundry, and then there’s some momentum stuff sprinkled in there. You know, you’ve always got to show that things are happening, people care. Then we have this part at the end that’s the vision-forward-looking thing.

I don’t know if anyone’s noticed, but we’ve been pretty clever with our little typographical stuff in there. We call this section The PaaS (R)evolution. I thought it would be a nice thing for us to talk about, because it’s a conversation that comes up all the time. You’ll notice when you hear Pivotal people talk, at least us, as I’ll do right now, Platform people talk, we always say ‘platform’ instead of ‘platform as a service.’ I think we have a good continuing reason in this end part of this conversation where I have these analysts of why we think about it. What we’re doing is more of a platform than just really just like a PaaS, if you will.

In fact, I think the title we have on one of these slides, I think you probably came up with this, was basically “PaaS as a feature,” which I wouldn’t say it’s counterintuitive, but it’s a little unexpected from where people think of Cloud Foundry, I should say, and other things. You just generally think of PaaS, but that’s really one of the things that we’ve come across quite a bit is, there’s a lot more scurrying around in Cloud Foundry, especially Pivotal Cloud Foundry, than just a PaaS.

Andrew Schafer:
You know me, Coté. Always be closing.

Coté:
Exactly, and I’ll always be inserting a large iceberg into the water, essentially, just the tip of it is PaaS. To that end, when you’re putting together these two talking points at the end, these two slides, why do you think of what we do as more of a platform than just a PaaS?

Andrew Schafer:
First of all, it’s all about me. I just can’t say the word. I hate the word. It just doesn’t even sound right. Doesn’t come off the tongue very well.

Coté:
Except as one of the commenters on one of your blog posts said, ‘around Easter.’

Andrew Schafer:
Around Easter, that’s right.

Coté:
That’s the perfect time for PAAS.

Andrew Schafer:
To which I responded, “I love you.”

Coté:
That’s right.

Andrew Schafer:
Just say it. Say it with me. PaaS. What is that? I don’t even know.

Coté:
PaaS, yes.

Andrew Schafer:
If you go back to before I was articulating this stuff for the analysts, I wrote a blog post a while ago called, The ‘as a Service’ is Silent. I don’t know if you ever read that one, …

Coté:
Absolutely.

Andrew Schafer:
… but first I started by the same complaint, that I hate this word and it sounds terrible, but that this is the de facto, that things are going to be as-a-service. If you move to this service-oriented microservices-driven world, then sure, everything’s a service. Why do we have to say that over and over? You’re going to drop that from everything, infrastructure, platforms, software. There you go. Done. You don’t need the made-up taxonomy.

Then the real problem is, those words were created for this convenient taxonomy, and you have the mis-definitions and people have been arguing about what is Cloud. It started with arguments about what is infrastructural service, then there’s this middle thing where I think it’s pretty clear what software as a service is, and it’s blurry a little bit, but there’s infrastructure on the computer network and storage that’s fairly pure. Then there’s this wide middle that everyone is confused about, or that anything you want can kind of be a platform, and that leads to all these false equivalence comparisons, I’ll call them, where people are trying to compare apples to oranges, and it’s just not good for anyone.

I think, at the point where you’re able to articulate the features you’re talking about, the benefits to outcomes, you’re going to have much stronger conversation than if you’re just trying to go through some checklist of things, because if you’re comparing the superficial installment of, my favorite example right now is the single instance of WordPress. There’s about two dozen solutions to that right now that everyone’s trying to market and put product around, that on that first pass, you’re going to have a WordPress. Good job.

You have one instance of WordPress, but it’s Day Two, it’s scaling, it’s the actual resilience of that. How does that thing go from now till the end of time? The other thing I’ve argued for a long time, and obviously, my background and you know my story, but maybe people don’t know how much of the DevOps and the rest of this conversation as …

My career basically revolves around trying to build and operate these things for a while, and operations is the competitive advantage. It’s just starting to get through to people that everything you do for software, especially in the service-oriented software, it’s going to spend the majority of its lifetime in maintenance and operations. Yeah, you want to get some stuff out, yeah, there’s the speed aspect of software development, but the actual costs over time for operating and maintaining your service will dwarf the development costs over time.

Coté:
Right, and that starts to become, to use the metaphor, the large chunk of ice underneath the water line. The beyond the tip of the iceberg is, yeah, actually running all this stuff on your own, as so many people seem to want to do, is a big deal, as you were saying. Then I think …

Andrew Schafer:
You can either do it well, or you can’t.

Coté:
Exactly.

Andrew Schafer:
People look at the features of something like an Amazon, AWS, and they rush to want to have those features. We have several examples of open source projects trying to solve that problem, but the advantage that Amazon has in this space is not that they figured out you could put an API in front of the hypervisor. It’s that they had, really, 15 years of experience managing a massive web infrastructure before that was what they were trying to do.

Coté:
Yeah. The famous Pizza as a Service chart from last summer, there’s a version back when I was doing analyst work, a version of that chart I made up that pointed out the fact that this is actually a great metaphor, and it’s funny, so gold star on that.

What it leaves out is the human part of it, the operations part. It’s not really modeled wiring all of this stuff together and making sure the staffing at home or at the restaurant or, to continue the metaphor, I’ve never worked in the pizza business, so I don’t know what the operations side is. I imagine it’s quite complicated if you want to extract a profit.

In fact, also if you only take, usually we use the word ‘product’ in a very positive way, because we’re trying to contrast project mentality versus product. To use it in a bad way: if you take only a product mentality towards building a cloud, I’m going to buy all these products and glue them together, it sort of leaves off that very difficult but ineffable part of, ‘Well, you need someones who are smart enough to wire this thing together on, as we like to say, the first day, on day one. Then day two, you’re also going to need a lot of people to run it for you. They’re going to need tools and things to support them.

Andrew Schafer:
Or you’re going to build software. That’s one of the things …

Coté:
Right, right, right.

Andrew Schafer:
… that differentiates the Googles and the Amazons of the world. Certainly part of what we’re trying to accomplish at Pivotal is that the problems that the traditional managed-hosting businesses solved with people, arbitraging cheap labor in Texas, if you will, those guys started solving with software a decade ago.

Coté:
There’s another angle of approach here that gets exciting for me. One issue, if you will, with a lot of Cloud stuff is basically, if I’m an ops person, I start to think, ‘So where do I fit in? What is it you need me to do again, because I would sure like to keep paying my bills and enjoying managing and configuring and operating these computers that I like so much.’

Andrew Schafer:
Let’s bring it back to the PaaS topic in a second, but I’ll just leave this one by saying that there’s still operational responsibilities.

Coté:
Exactly.

Andrew Schafer:
It just shifts where they are, and you’re going to spend less time worrying about racking and stacking, and even configuring systems, and more time worrying about delivering business value and understanding, ‘Okay, when something’s down, there’s still going to be incidents.’ You’re still going to have to respond to them. It just shifts where in the stack you’re really going to focus.

Coté:
Right. No, and that’s exactly the thing I was getting to is, there’s still some exciting work for operations people to do for sure. In fact, it’s much better than just being a wire-monkey and just hooking things up and handling hardware. There’s a lot more interesting problems and things to worry about, which is nice. There’s not always that sort of message you get with Cloud. A lot of it seems to be about automating operations people away. There’s just a changing nature of what they do.

To that point, it’s almost like there’s a renewal of the contract between your application layer and the operation layer that, as we were alluding to earlier, do you want to spend time building your Cloud and worrying about all that stuff, getting to that blinking cursor I’m always making fun of, or do you want to write your applications?

Andrew Schafer:
Good job configuring servers this year, guys.

Coté:
Exactly. To me, that’s the start of why we say ‘platform’ a lot more than just ‘PaaS,’ if you will. To me, ‘platform’ is like, if I’m writing an application, a piece of software, I’m going to need a platform. I’ve always basically needed a platform, whether it’s something as simple as Rails, or PHP, or Java, or I’ve built my own platform, which I’ve seen plenty of times in my career. It’s always an exciting adventure to go through. Essentially more of what you’re seeing delivered in what we would call the PaaS phase, is more people talking about delivering this whole platform that application developers can start using, which shifts it around.

Andrew Schafer:
Let’s go back a step and then build up to that.

In the beginning, I was taking a hard line, because I’m a zealot. I didn’t want to talk about PaaS at all. I didn’t like the word so much that I just didn’t want anyone to say it. Then the market says it, the customers say it, certainly people at Pivotal say it, and I finally softened and I had an epiphany.

What I realized and came to understand is that PaaS as a thing, if there is such a thing, is that veneer, that service layer that lets you, with an API: we expose API, you can deploy your code. I think it’s a defensible definition under NIS, and looking at the history of what the label is initially applied to from Heroku to App Engine to Azure, at least the first version of Azure, that you have some API, and you push code, and it runs, and everyone’s happy.

Then, when you look at what Cloud Foundry does, there’s so much more to that. Really, it’s easy to understand this if you just back up and think about, ‘Okay, if we accept this definition of ‘as a service,’ the infrastructure as a service exposes APIs to give me infrastructure, platform as a service exposes APIs to give me this deployment. What is the underlying thing, and how does Heroku deploy Heroku? How does Ajurry deploy Ajurry, or App Engine deploy App Engine, because it’s certainly not with the PaaS. The PaaS does not deploy itself, so how do you manage that thing? What is the life cycle or the operating responsibilities of that thing?

Then you look at what’s available in the Cloud Foundry ecosystem and some of the tools. I just did a talk about BOSH with you in Belgium. Those are the things that fill that in, and I think that’s one of the unique values of what’s being built around Cloud Foundry right now, relative to some of the other things, is that those tools are not as integrated.

Someone goes to deploy OpenStack. How do you deploy OpenStack? You go grab whatever your favorite configuration management is, or every once in a while, someone says they’re deploying OpenStack with DevStack, and I’m like, ‘What are you talking about?’ But the tooling in cloud native, if you think about what’s going on at Amazon, what’s going on at Google, and really, what’s been going on for the last five, ten years, that whole thing is software.

There’s software that deploys software. There’s a contract between that deployment and the actual deployed software, and that’s maintained in a way that is both constraining and liberating.

I think one way to frame that which is easy for people to understand, at least in our circle is, yeah, you only have 140 characters, but you could do a lot with 140 characters. The constraints give you more than the …

Coté:
Exactly. Yeah, it’s almost like we have a gluttony problem in IT, where if you put stuff in front of us, or give us options, we’ll eat it, sort of my eating method style. Any food you put in front of me, I’ll eat. To some extent, it’s nice to have constraints if you have that disorder.

Andrew Schafer:
To some extent, that’s the betrayal of enterprise software. The last few decades of enterprise software, it’s been this war over who could have the feature matrix, and people are often buying software that they don’t think about systemically. A lot of times, they don’t have any experience with the technology, and they’re not going to be the ones to use it, because of the way the selling happens through executive channels.

As a consequence, for the longest time, pre-GitHub, pre-Twitter, pre-free flow of information, a lot of software was just sold on whoever could cram the most features into a presentation and show it to the executives.

Coté:
It’s little wonder there’s so much shelf-ware. It’s almost like, Don’t Need It Ware, in certain circumstances. It’s overfeatureitis.

Getting back to the …

Andrew Schafer:
Well, it sounded like such a great idea on the golf course.

Coté:
Exactly, or in that conference room. It’s probably one of those early morning things, instead of the enlightening, low-level lights of evening chatter.

Andrew Schafer: All deals should be done after midnight.

Coté:
That’s right. It is like, you have a phrase that we use all the time that’s fun, ‘Who deploys Heroku?’ Who sets that up, and who configures it? That starts to point toward the challenge, essentially, like managing that big mass of the stuff becomes quite difficult.

We’ll see how it plays out, but to a certain extent, what you want from, to use the word, a platform, one of these platforms you’re talking about, is at the end of the day, the software development part is not really as difficult as all the other parts. You want that part to be easy so difficulty can be focused on your application and you spend your effort on that.

It’s almost okay for the operations part to be a little more difficult, it seems, as long as there’s help for you there. To use that old Mark Pilgrim quote that I always like, ‘A lot of effort went into making this effortless.’

I think, from the vantage point of a software developer, the end result should be this effortlessness of, ‘Oh, I’m deploying my Buildpacks and doing this stuff, and la, la, la, things are great,’ and I can spend all my effort on designing something that actually people want to use and pay for, which is not easy.

Andrew Schafer:
To be fair, there’s plenty of hard problems in software development.

Coté:
Exactly, but figuring how to configure a Cloud shouldn’t be one of them.

Andrew Schafer:
Right, and if you’re spending half of your time worrying about the way that you’re going to configure this little thing with this disk and this network and the rest of it, you’re not focused on the business value. It’s not that someone shouldn’t solve those things, it’s just that it doesn’t have to always be you, doing everything, every single time, starting from the beginning.

Coté:
When you think about it, what do you think the scope of the platform becomes? How much of everything do you bake into it? Do you put in plenty of monitoring and a service desk, or where do the lines start to get drawn, of what’s in the platform?

Andrew Schafer:
I think there’s a few ways to think about this. I would back up a little bit and frame things. You just mentioned Buildpakcs. “Buildpakcs” is a wording that was borrowed from Heroku, and Heroku has this manifesto around 12 Factor Apps and what it means to be a 12 Factor App.

If you walk through that list of things, that’s all well and great, and if you really understand how things get deployed and scaled, you can read between the lines and see how that benefits you from the deployment and pipeline, and all the things that you’d like to be able to do in this Cloud Native rapid world.

Then you have things in there that’s like the application will run as a stateless process, which sounds great. Its trivial to scale stateless processes horizontally, that’s great, but that is implying that you have to have state that lives somewhere else, because an app will fill out some state, somewhere. What is that? What are you going to be able to do? You’re going to have a random number generator? I don’t know. There’s got to be some state.

Coté:
I always think you can play that Bejeweled game. I think Bejeweled can be stateless, so that’s fine.

Andrew Schafer:
Well, unless you want to keep track of your …

Coté:
Your high scores, right?

Andrew Schafer:
Sure. There’s a bunch of absurd observations we could make about a bunch of things, but at the end of the day, most of the interesting things are going to have some state.

Coté:
Indeed.

Andrew Schafer:
That means that state has to live somewhere else, and if you’re deploying to Heroku, what they’ve done is, they don’t just operationalize this veneer that is the API. They’ve also operationalized these other data services that are also run as a service. I think that’s one of the differentiating things that we’re seeing evolve in the Cloud Foundry ecosystem. The PaaS as a feature argument is, I’m saying, ‘Okay, here’s this elastic runtime that allows you to deploy your 12 Factor stateless apps. As a consequence of that contract as a 12 Factor App, the platform is going to provide the other side of that contract, and it’s going to give you a place for you to store that state.

It’s going to give you whatever the mechanisms are to take advantage of the fact that you have separated these things, the build, run, compile stuff, one of the 12 Factors is, you’re going to inject information at runtime into the environment. Well, something has to do that, and the platforms providing the other part of that equation.

As a consequence, the tooling that we’re building not only gives you a platform as a service, but it’s also giving you a generic, as-a-Service template. We’re building a fairly impressive database as a service, using the MySQL Galera stuff that’s getting released. There’s a number of other things, there’s Cassandra Riak, MongoDB, the rest of these things. Also, going and filling out the rest of that functionality ecosystem, we have the ability to provision and run as a service Jenkins, the Spring Cloud stuff that we’re going to see, take advantage of some of the Netflix Open Source.

All these things are not just, ‘Oh, hey, here’s a cute little thing.’ It’s actually running ‘as a Service’ with the same kind of guarantees around resilience, the same kind of fault tolerance, the same kind of health checks and remediation that you’re getting in the rest of the platform. I think that’s what’s exciting, that’s what’s changing things from just being able to install and configure single instance of WordPress. It’s actually the full life cycle management baked into one place.

Then the rest of those questions about what goes into platform and what doesn’t go into platform, I think that the platform is that contract, being able to maintain those other things as a service, and then you can make decisions about what you want, because there’s a spectrum of context. I think it’s dangerous to say everything should be everything for everyone. You have to recognize that across verticals and different types of projects, different types of teams, different sides of teams are going to have different needs, so being able to run things as a service inside of the platform itself gives you the ability to choose where that functionality is.

Then giving yourself APIs to connect to the services that you install, connect these different things we’re just talking about, this is one of the powers of modular microservices, service-oriented approaches. Apigee has this API management thing. This is just an off-the-cuff conversation. It would be trivial to put Apogee under the routing layer for any app on Cloud Foundry just because we’ve already built in the way to add those hooks and defer and proxy the requests.

There’s certainly things that I think the platform should provide, but mostly, I think it should focus on that kind of life cycle from the operational perspective, and the rest of that is going to be as you need, based on your context. If you’re a team of six people, you might have different context than if you’re trying to manage thousands of developers. Then you’re going to decide what you need.

Coté:
Right, and then to go back to the, ‘all you need to run a Cloud is 140 characters jag,’ so to speak, that’s part of what you would expect a platform to specify. ‘Here’s the constraints,’ to us a word we never use anymore, ‘that basically a ‘plugin’ can use.’ If you want to inject something into this, or build on top of it if it doesn’t provide it for you, or you don’t like the way it’s providing, because this is a platform that basically manages a bunch of services and runs those services, what you’re wanting to add is the service itself. No problem, that’s what we do. You don’t necessarily have to.

Back in the old APM days, there we’re pretty much all application performance management things, or hacks around the VM to get access to things that you needed, if you have a well-specified platform, things are pretty transparent and open. Not only that, but it’ll also run it for you and take care of making sure it can scale up.

Certainly, I think that starts to be one of these platform all the way down recursive mine traps, but once you realize that the whole thing is just running services, essentially, you start to realize how much you can add on top of it, and you can expand it out to fit whatever these things may be.

If there is a service desk for whatever, that’s always my hokey systems management to choose, but whatever it is you might want to choose, the platform is there to help you run it, instead of being this sort of black box, combatting you against running it and requiring all sorts of crazy little hacks.

Andrew Schafer:
Right. In the newest release that’s coming out, there’s APIs for doing notifications to users, and that’s whatever you can think of, just events that happen in the platform, we’re now going to be able to notify through API and Alerting. You could imagine if you have some flow that you want to connect, you could just connect those alerts to whatever that other system is. That other system could also be running inside of Cloud Foundry, so then you have this full loop that’s going to take alerts from the platform and put it into whatever other thing you want.

We had a very interesting Cloud Foundry After Dark last night focus on The Internet of Things and pointing out that the approaches to scale the ingest and indexing, and just the sheer size of the data that you’re going to have if you even do a moderate build-out of devices that are sending time series data is going to put anyone who’s trying to do that on essentially the scale that no one except for maybe the Googles and the Amazons had seen until a decade ago.

Being able to solve that problem is going to be important to stay competitive or to participate in that. Most of the IT, going back to whatever we were talking about before with the identity people have attached to the tasks they do there, are not really prepared to live in that world. Their mindset of doing these things manually and operating these things manually just isn’t going to work in the world where you have literally millions if not billions of connected devices, and they’re all streaming time series data back to this thing, and you want to make sense of it.

That’s going to be fun, but there’s also going to be a rude awakening for a lot of people trying to do that, not quite understanding. Basically, you have to learn this the hard way, I think, and some of the lessons that Amazon learned 15 years ago, you don’t have to learn, because one of the guys that worked at Amazon at that time was working on our stuff at Pivotal and trying to build out these solutions for solving that problem in a way that the people could take advantage of someone who had already learned that the hard way.

Coté:
Yeah, I know, and to your point of The Internet of Things being potentially a rude awakening for some people, I remember four years ago or so, whenever that term starting being bandied about, it seemed delightful but not very mainstream. Nowadays, you can basically see the signs of this oncoming data onslaught. You just go to the hardware store, and there’s all these little thermostat devices. This is just in the consumer space.

The point is, if you think about various categories of your life in a personal and business sense, more and more of the things you deal with, to use the word, are basically getting on the network. If you unravel that system, all that data is essentially going somewhere, and that’s a lot of data that’s moving around.

Someone was telling me that Wendy’s is experimenting with putting cameras on heads of lettuce, I guess to get the farm-to-market hipster crowd, or something, to buy their burgers. The Internet of Things always seemed like an industrial, weird concern, but really what will be annoying or exciting for businesses to deal with is, if I have this onslaught of data, what am I going to do with it? I think it’ll be fun to see what they come up with.

Andrew Schafer:
I don’t know if you get into Mary Meeker, but she’s at Kleiner Perkins, and she does an annual report. It’s always insightful, but one of the things that she had in the last one is this, basically, in order of magnitude increase of every build-out, going from mainframe, up through the desktop PC, to mobile, to this Internet of Things.

If you think about what a platform really represents, I think we’re trying to build, and what will converge is the level of an operating system going back to the early days, or even the databases, where you see this expansion as the problem becomes, … This is also stuff Simon Wardley talks about, but as the problem becomes apparent, there’ll be innovations to try to solve the problem. Then it’ll be productized, and eventually it’ll become this standard commodity, where you just take it for granted that you can write to a POSIX-compliant operating system, and it’ll just do the right thing. You don’t have to go solve that problem.

I think that being able to put these things together in a way that they become a de facto solution that is not just the ‘standard,’ but actually a solution and allows people to focus on the things they want to do, and not on how are they going to deploy this new thing.

Coté:
Yeah. Yeah. Well, this has been good.

One of the things that, when we were going over this, when we were talking, I was thinking, I remember over the past maybe three years or so, there’s been two types of cloud conversations I’ve had with people back when I was working on strategy or as an analyst. There’s the properly taxonomized people, the people who would talk about, we’re at the infrastructure layer, the PaaS layer, or the SaaS layer, essentially, going over whatever it is that they have to offer in that category. Those are nice, easy, tidy conversations to have, because they’re well-categorized.

Then there’s this whole other category of conversations that have been happening more and more over the past year, like, ‘We work on Cloud stuff,’ and there’s really no category for it to fit in perfectly. A lot of those conversations, including with Pivotal when I was on the other side of the door, as it were, we’re really talking about, ‘We’re building a platform so that you can build stuff on top of Cloudy IT.’

In order to build that kind of platform, you need to do all this stuff that crosses categories, if you will. It doesn’t fit nicely into these buckets, so I think reconnecting a bit of a lot of the conversations I’ve had over the past three years, it’s easier to understand what that second category of conversations were if you take this more platform mentality approach to it, rather than just the classic, whatever we used to call them, “SPI” categories? Those were good times, but while the NIST thing is nice and tidy, I think nowadays, it speaks more toward components that you would use in building an overall platform.

Andrew Schafer:
I don’t think anyone ever solved their problem focusing on the taxonomy. You want to focus on the outcome. I think that the tidiness in an emerging technology, while it might be inconvenient to have the ambiguity, it’s necessary as you figure out what this stuff actually should look like.

Coté:
Exactly.

Well, with that, we’ll see everyone next time.

About the Author

Biography

Previous
All Things Pivotal Podcast Episode #23–You are Going to Need a Platform, Operational Concerns of the Third Platform
All Things Pivotal Podcast Episode #23–You are Going to Need a Platform, Operational Concerns of the Third Platform

In this podcast, Michael Coté talks with Andrew Clay Shafer about one of his works in progress, a short ess...

Next
Case Study: Refactoring A Monolith Into A Cloud-Native App (Part 3)
Case Study: Refactoring A Monolith Into A Cloud-Native App (Part 3)

In the first two installments of this series, we began refactoring the monolithic SpringTrader application ...

×

Subscribe to our Newsletter

!
Thank you!
Error - something went wrong!