VMware, not too long ago, picked up SpringSource and associated technologies, painting a clear Java stack play. But looking at Integrien and TriCipher, we’re starting to see real building blocks around application level services that are well beyond the bounds of a VM. This is all extremely interesting; it points to the notion that VMware is evolving to see the application layer as the key battleground of the future. I know it seems obvious, but looking at all the moving parts, it’s always amazing to see things like this come together. I personally believe that we’ll see full blown stack analogs in the cloud, along with best of breed semantics, creating a true set of “cloud stacks” that offer huge amounts of value to the application tier, and not just focus on solving infrastructure level problems (which is what a huge amount of cloud tech as focused on to date. Not all, but a large amount)

If you were VMware, what other application level services an components would you see as critical in building a complete stack offering?  At what point would the VMware stack evolve into something unique rather than just the sum of its parts?

1. The first time it is run
2. The first time it is tested under duress
3. Use in the real world

When people envision others writing code, they envision dozens of programmers writing text, deploying code, and using it. If it only were so simple. This make-believe scenario assumes that the only tool a developer uses is some sort of text editor/development environment. This is far from reality. Writing software typically requires the use of a number of advanced tools and techniques: debuggers (with the ability to work with real, running code), performance profiling tools, memory profiling tools, tuning tools for database queries, abilities to change the underlying runtime mechanics of your platform - you get the point. The reason for all of this is that code does not run as we expect it to, and this becomes painfully apparent at the three inflection points I described.

Interestingly, the general complexity of business software has been increasing. That is, business apps try to tackle more complex problems as each company tries to outdo their competitors by offering the market more value. This means that code also becomes more complex, tooling becomes more important, and visibility into an application becomes key.

Why then, did PaaS offerings (think Force.com style abstract PaaS offerings, particularly in the Apex only days) start off with such a “lowest common denominator” platform? Since business apps are becoming increasingly complex, and PaaS offerings presented a layer much less sophisticated than traditional platforms like .NET, how pragmatic are they for ISVs? As a tool for extending a CRM system, Force.com is clearly great stuff. It offers a simple way to provide new value to an existing system. But as a platform for serious ISVs who need to build complex offerings  - that’s a stretch. The complexity required of a serious development platform just isn’t there, and most software companies should recognize that. There are so many questions that are currently unanswered that make modern PaaS offerings unrealistic for many, many scenarios. Interestingly, these questions are unanswered for at least one (if not all) of the lifecycle inflection points I defined earlier:

1. How can I debug a live Force.com (as in real, “attach to the code and see what’s going on” debugging)?
2. My customers are complaining about speed, how can I performance profile and tune the application?
3. How can I optimize around certain types of resource consumption?
4. I can I use new architecture techniques if the PaaS is too limiting (think Apex before asynchronous calls - a concept that has existed in mature platforms for quite some time)
5. My application is not working as expected in production, and my developers need access to system specifics and the running code to assess what’s going on, how do I get to the live runtime?

I could go on for a long time.  Fundamentally, PaaS offerings seem far too trivial with VERY immature tooling. Yeah, yeah - you’ll here the “In PaaS X, you’ll never have to worry about Y.” The fact of the matter is, code rarely meets expectation at those inflection points, and developers need to dig deep to make magic happen. PaaS offerings really trivialize this. It reminds me of the days when WYSIWYG editors were going to “revolutionize” how websites were made (think Frontpage, Homesite, etc.) and that web design would be democratized, and no one would have to touch HTML, JavaScript etc. We all know how that turned out. The concept of “everything can be written for you, no need to “hand tweak” has never worked at scale, and typically has failed miserably. The best web properties are still written “low level” (relative to web technologies), and complex tools and libraries for JavaScript, Flash, and Silverlight are flourishing.

“Old” runtimes can do a far better job than PaaS when coupled with purpose-built middleware for SaaS and cloud infrastructure like EC2. Developers can capture complex requirements and systems with the right languages and have all the real world tools needed to properly build, test, and evolve software.

Do you feel that PaaS offerings nailed it, or do you agree that they missed the mark and currently cannot support high levels of complexity and real software development life cycles? Is PaaS currently a reflection of WYSIWYG web editors and we’ll instead see a cloud stack evolve that doesn’t try to “solve everything” in one silo?

I had the pleasure of reading a Structure 2010 follow up article written by Stephen Lawson titled “VMware’s Maritz: OSes are having their jobs stolen.” In it, Lawson outlines VMWare’s CEO Paul Maritz’ position that modern applications are relying on frameworks farther up on the stack for abstract services that used to be provided by the operating system, and that those frameworks insulate the application from even knowing what the operating system is.

This “commoditization” of the server OS is expected to some degree and is a case of “what’s old is new again.” Looking back through history, we’ve seen software development take on an evolutionary path of abstraction. Starting from assembly (x86 is my personal reference point) through higher order abstractions like C++ through byte code targeting virtual machines (as in the JVM and .NET CLR), we’ve always looked to move away from various OS level complexities in an effort to boost productivity, increase maintainability, and reduce coupling risk. However, these benefits were only considered OK so long as it didn’t jeopardize the programmers’ ability to express complex solutions to complex problems because of functional crippling that might arise from being too abstract. Typically, two things have held true:

1. New paradigms in solution expressiveness have driven the introduction of new languages that embody those paradigms. For example, once “modeling” became en vogue, object oriented programming made sense. Now, we’re seeing a resurgence of functional languages or hybrids.
2. Transitions in delivery paradigm have typically acted as catalysts to the creation of new frameworks (passive libraries) and runtime technologies (active application layers) to support the new delivery paradigm.

What we’re seeing today in that Cloud is that scale of technology coupled with the introduction of new application architectures and delivery needs that operating systems were not built for. OS’ are general purpose beasts with explicit and valuable capabilities and coordinating a fundamental execution platform. They are not specialized enough to really understand the upstack pressures being exerted on software developers. Clearly, they could be modified to do so, but were never meant to constantly evolve in that fashion. Instead, they are participating as a critical component at the bottom part of a stack.

When we look at SaaS and some of the architecture dimensions specific to SaaS such as multi-tenancy, the need to be able to achieve web-scale, and have operating tools in place to manage the application, we start to see that new modern frameworks, and in many cases, new types of middleware, are needed. This is the whole motivation behind why I helped co-found Apprenda and we set out to create SaaSGrid. In the early days, my co-founders and I frequently had conversations about how today’s applications need not know about OS specifics in order to function properly, which lead to some of the early architecture decisions of having SaaSGrid act as a mechanism that would leverage the decoupling of app components from their underlying network and OS dependencies to help facilitate scale-out (many details, of course, which go beyond the scope of this post.) As SaaSGrid matured, it took on a number of architectural dimensions on a guest application’s behalf, such as providing baseline single instance, multi-tenancy at all tiers or scaling out by offering partitioning services that can help reorganize application component distribution across a network of servers without reconfiguring or rewriting parts of the application. In effect, SaaSGrid started to manifest a number of “OS-like” capabilities, which go far beyond the frameworks that Maritz describes. It seems inevitable that upstack pressures will also hoist value-add solutions away from the core machine/VM OS, but we should all remember that a stack isn’t a stack if the bottom-most piece is missing or instable.The traditional server OS has simply transformed from necessary and sufficient to necessary but not sufficient.

Do you agree that the server OS is becoming commoditized with respect to cloud offerings, or is this an over-dramatization of what’s happening? If you feel the OS is fading into the backdrop, is there an opportunity for the OS to “modernize,” and if so, how?

I was lucky enough to be on this panel with a number of very intelligent people who had some amazing insight into the topic. One of the questions posed to the panel really struck a chord. Essentially, the question was something along the lines of “Are standards necessary for the hybrid cloud to become a reality?” (Roughly minute 29:07 in the recording) The standards being referred to are standards that would abstract the command and control of virtual infrastructure. Each cloud provider (e.g., Amazon through EC2, GoGrid, etc.) typically provides an API by which one can control the deployment and ongoing operations of a virtual resource. Since each cloud provider has a different API, there is a form of lock-in that rears its head since, although each cloud might provide a similar container (say, a Windows 2008 Server), your code for managing and leveraging that cloud is non-portable.

Mårten Mickos, CEO of Eucalyptus, fielded the question stating that standards are necessary for hybrid cloud to really take off and that a standard would accelerate adoption significantly. I agree with the spirit behind Mårten’s view, but not with the idea of formal standards (and as you’ll read, I think Eucalyptus is poised to do some amazing things). Now when we discuss “standards” we mean an industry standard sponsored by a standards body or some sort of consortium. Others on the panel respectfully disagreed with Mårten’s position. Joe Weinman responded that standards aren’t necessary, and that different providers need to be free to evolve solutions that best fit the problem domain and customer need. My position was somewhat in alignment with Joe’s; standards, by definition, must cater to lowest common denominator subsystems which can bias efforts towards standardization rather than on new techniques to solve new problems in the cloud. It’s important to understand why this is the case, and also why it doesn’t mean that although a formal standard shouldn’t be pursued in the near term, generalization should absolutely be pursued.

In some instances, “formal” standards can stifle innovation or distract focus from solving specific problems by becoming abstract enough to be standards compliant, but not specific enough to solve a problem as well as possible. For example, if some cloud provider comes up with a novel way to address something new, they can still conform to the standard, but any uniqueness they bring to the table will be lost behind the abstraction. Just think of the SQL-92 standard. Most every DB vendor has some level of conformity, but various RDBMS’ do something amazingly useful things outside of the SQL-92 standard. If you leverage those proprietary pieces, you can no longer benefit (at least not by much) from the standard itself since you’ve broken conformity. Furthermore, any standards that have evolved in the past have typically fragmented into many sub-standards, dialects, etc. (just like the SQL case)

Now, does this mean that we shouldn’t pursue standardization? Well, if we’re talking about a “formal” standard, we probably don’t need to rush it. Technological generalization, however, is a different story. We’re at a point in the cloud’s evolution that requires organizations like Eucalyptus to focus on providing a coherent means to manage multiple specific cloud implementations. This is amazingly powerful and valuable and doesn’t require a formal standard. Eucalyptus has focused generalizing the Amazon EC2 API as a standard API that could be applied against any other cloud system. Overall, EC2 is a wise choice since it has the broadest market penetration and the most generally applicable API when looking from an abstraction point of view. Eucalyptus is doing some amazing work to make sure that you can leverage API expectations to work with a variety of virtualization clouds. Their efforts will undoubtedly boost adoptability, reduce adoption risk, and increase the viability of private and hybrid cloud deployments. Given Amazon’s API penetration, a market “gold standard” has been created just by shear adoption, and I think people will naturally flock to a proper abstraction like Eucalyptus because of sheer necessity to ensure compatibility with the gold standard while preserving the ability to experiment with new solutions. By choosing EC2, Eucalyptus’ approach provides a standards-like advantage without the baggage since the standard is chasing the market leader, rather than creating a standard and trying to enforce it. Kudos to Mårten and Eucalyptus for helping catalyze adoption of the cloud!

Do you feel that formal API standardization will be absolutely required in order for cloud, private cloud, or hybrid cloud to work, or will things organically tend to a relatively standard oligopoly of well known abstractions without a formal standard in place? Do standards create stifle and slow down innovation by always focusing on the lowest common denominator, or does it promote innovation by guaranteeing a baseline?

]]> http://www.saasblogs.com/2010/06/26/do-we-need-cloud-api-standards/feed/ http://www.saasblogs.com/2010/06/07/saas-for-the-isv-masses-through-saasgrid-express/ http://www.saasblogs.com/2010/06/07/saas-for-the-isv-masses-through-saasgrid-express/#comments Mon, 07 Jun 2010 17:44:43 +0000 Sinclair Schuller http://www.saasblogs.com/?p=286 When my partners and I co-founded Apprenda, we had a number of very specific goals when it came to SaaS enablement and we wanted SaaSGrid to embody those goals. My co-founders and I all came from technical backgrounds where we were responsible for SaaS engineering efforts. We learned early on that when a SaaS application is engineered properly, its architecture is drastically different than plain old web applications (think multi-tenancy and scale-out) and that a huge number of auxilliary tools and subsystems (think billing, application life-cycle management, infrastructure management, subscriptions, identity federation, etc. and then some) are necessary for managing and operating a SaaS offering and business.

When you combined these “SaaS specific” aspects of a SaaS offering, the upfront and ongoing time and money investment required far eclipsed that of the application itself (the actual thing your customers want to pay you for!), and causes huge competency distraction. Taking on the build out and maintenance of a mature “SaaS stack” is akin to a software company deciding that it’s in their best interest to build and maintain their own DB technology in support of their business application.  Surely, most people buy RDBMS tech (like SQL Server) or download it (like PostgreSQL) to help ensure succcess, and firmly believe that they need not build their own. When we created SaaSGrid, we had some very specific things we wanted it to do:

1. Allow for the use of traditional stacks (in our case, the Microsoft .NET platform) and the wealth of tools and components already in existence for these stacks. New languages are best created in support of new modeling paradigms or changes in the ways we capture solutions, and not in support of a new delivery model. Traditional runtimes simply needed to be “enhanced” to really sing in an on-demand scenario.
2. Have it be comprehensive and not require a “paper mâché” approach to piecing together disjointed capabilities. Imagine that an operating system required that you find your networking substack from here, and a graphics subsystem from there, and then require that you mash them together. That would be sub-optimal in many ways.
3. Have SaaSGrid provide even the most complex capabilities, like multi-tenancy, as transparently as possible to the application code that runs on top of it. As technologists, we hate having technologies adulterate our code, so to the extent possible, we wanted SaaSGrid to be as low impact as possible.

We accomplished our goals and some, and our customers benefit wildly from SaaSGrid. But late last year, we were thinking about a number of things related to the market and to SaaSGrid. As a company, we’re committed to not only supporting the transition to SaaS, but to catalyzing it. I think great strides have been made with respect to software company adoption of the new delivery model, but the fact of the matter is, most ISVs are still not SaaS. Furthermore, those that want to become serious SaaS players have a tough time understanding how they can get there and what tools are available to them.

Enter SaaSGrid Express!

Anyone that follows my company Apprenda knows that we recently made a new product announcement with SaaSGrid Express. SaaSGrid Express is a freely downloadable application server that captures nearly all of the value of our tried and true SaaSGrid, and that can be used by anyone just to experiment or even to build a revenue producing business. Our goal with SaaSGrid Express is to let everyone experience the value that SaaSGrid has to offer, and more importantly, to democratize a highly complex SaaS architecture in hopes of moving the industry forward.

Phil Wainewright recently offered some excellent insight in his recent blog post regarding SaaSGrid Express; the goal of democratization also means that some people might get there hands on a technology but are simply not prepared to build their own clouds. But as Wainewright went on to point out, those same people would have gone down that path with or without SaaSGrid, so we’re happy that they’ll be able to walk away with such a robust starting point. Giving SaaSGrid Express to the world means that more people than ever before can experiment with and commit to a proper SaaS architecture, which will definitely help satisfy our vision of catalyzing the space. As Dana Gardner suggested, SaaSGrid Express opens up the potential for a “cloud standard” architecture and SaaS stack. If we accomplish that sort of de-facto standard, then the industry is definitely off to a good start. Having a de-facto SaaS stack means that people are not focusing on complex architectures, but on business value for their customers - which would be a huge win for everyone.

Something Special for YOU!

For those loyal SaaSBlogs readers that have an interest in downloading SaaSGrid Express and building an application, we’d like to offer you something special:

For the first 5 SaaSBlogs readers that sign up for SaaSGrid Express with the intention of building an application, or migrating your existing .NET offering, we’ll commit 1 hour of time from one of our engineers to personally work with you, and get you up and running with your project!

Just mention that you’d like to take us up on this special SaaSBlogs community offer in the comments section of the sign up form.

Given that there is so much velocity, tumultuousness and general confusion (acronym hell coupled with taxonomical conflation - aka the “everything and everyone is a platform” syndrome), we’re bound to see some order evolve in the future where the evolution will be motivated by what people actually use and adopt rather than the current landscape which is driven by who can yell the loudest.

The big question is what will the future of cloud architecture look like: a stack of interchangeable layers that allow one to choose best of breed or a group of incompatible but highly specialized “holistic silos?”

Looking at the history of infrastructure middleware, the answer seems to be quite clear. Typically, the trend has been that layering functional best of breeds into stacks provides the best combination of “lowest common denominator” coupled with the necessary functional value to “get things done” and keep risk minimal. For example, I can choose servers made by HP, a Windows OS, Java and JBoss, and build a killer enterprise app. If I so decided, I could have swapped Windows for Linux and essentially had a compatible stack experience.  Why, then, are silos cropping up in the market?

Silos like Force.com have their appeal. They promise a world where all your needs, ranging from hosting and execution runtimes in the cloud all the way through development frameworks and distribution channels. The problem, however, is that the software market cannot be addressed as a broad stroke.

The needs of software companies vary wildly: ISVs in the healthcare space may care more about hosting certifications than someone in the CRM space, while those in business intelligence need low latency, high compute availability and the others who altogether care very little about the hosting and it’s all about what middleware they are going to use. The number of needs permutations is staggering.

To think that Platform as a Service vendors that own the full stack, from hosting through runtime and even UI components, can ever optimize for each of these scenarios is ludicrous.  Furthermore, the silo providers ask for something huge in return for a suboptimal solution:  control of the ISVs destiny in all regards. That’s a high price to pay for a promise that can’t be fulfilled.

I’m a firm believer that most if not all software will be delivered online. It’s the only way to achieve true ubiquity, and it requires superior delivery. Each ISV is going to have to make lots of decisions as they move to the SaaS delivery model. Those decisions are going to focus on how to best solve all the critical problems associated with becoming a service provider. The only logical conclusion is that each ISV will look for best of breed tiers in a stack form that would allow them to create an optimized outcome. I don’t see a grand future unfolding where thousands of ISVs worldwide commit to incompatible silos that require taking on relationships that amount to single points of failure and risk. As a stack becomes more vertically consolidated (i.e., more siloed), the higher the risk grows for an ISV. If ISVs take on piece-meal stacks composed of highly compatible tiers, the walk away with the best of both worlds.

What do you think? Do you think that the next generation of business applications will be split across walled silos, or will the market adopt levels of commonality by converging to a stack approach with solutions provided by a few key companies at each layer, allowing for a “composable” stack approach that we’ve grown accustomed to?

Force.com is a high order abstraction requiring the use of a new programming language and a heavily diluted (read crippled) runtime. As a platform for extending the CRM functionality of Salesforce.com, it’s an amazing platform. As a general purpose platform for business applications, I think it’s too trivial of a runtime (anyone who’s read this blog before knows my position on this). Most mid-large ISVs solve complex problems addressable only through mature, expressive languages and complete runtimes and stacks. VMForce might be a step in the right direction - so let’s wait and see!

PS: For the literalists out there, one thing I noticed is that VMForce.com describes  it as a “product announcement” instead of “service announcement”. Maybe it’s some sort of special VMWare on-premises integration to the Salesforce.com Cloud?

What do you think VMForce is all about? Any drastically different theories?

Service. Let’s assume that “service” can be broken down into three main processes: engagement, implementation and execution. Engagement is the act of committing to use a service (e.g., signing a home builder to build your next home or remodel your existing home), implementation is overhead required to initiate use of a service, and execution is the process whereby the service provider performs its intended “statement of work” to yield an expected, implicitly or explicitly agreed upon result. I’ll use these process labels in my little analysis of what I see in SaaS.

If we dig in more, when we think of “service” we usually think of scenarios where, for a fee, some external entity completes a task or series of tasks on our behalf and produces some intended result. Second, I would say that it is generally understood that the service provider and the customer have a fundamental point of “equilibrium” with respect to knowledge required to provide the service and the knowledge required to engage a service. Yes, the knowledge can be skewed in one direction or another (As a trivialized example, a customer who is a Hollywood Socialite simply stating “I want a nice house” vs. anyone else stating “I want a two-story colonial with a basement, geo-thermal heating/cooling, solar power, and manufactured with a steel frame” places a heftier knowledge burden on the contractor that will ultimately build the house, while also increasing the contractor’s probability of failure since no clear requirements were presented.)

Rarely do we think of scenarios that require significant amounts of effort on the customer’s part to kick-off the engagement. For example, which is more typical:

• Having a contractor come to your house to provide you a work estimate based on his/her measurements and discussions with local officials.

OR

• Having the contractor come to your house and tell you “Great, nice house. All I need next is for you to go off and take measurements of your house, identify any new structural components and provide measurements for those as well, take care of architectural drawings, and deal with the town all by yourself regarding requisite approvals, and then I’ll give you an estimate.”

Ok, I know, some contractors do that, but what was your first thought? That’s right: “I’m planning on hiring and paying you and you want me to do what?!?!” Same goes for almost any service. Furthermore, we don’t couple the act of engaging the contractor with implementation; that is, we don’t tie the decision to use a contractor with the act of going out with that contractor to a supply store to pick out construction materials like wood, nails, and insulation. In fact, if a contractor ever said “Well, while we’re working on a contract together, let’s go out and start selecting what we’re going to use” we’d run for the hills simply because of the sheer idiocy of the request on the contractor’s part.

We expect that the engagement phase will be as trivial as is common for that type of service; we understand what the service intends to do, we have either an implicit knowledge of what implementation entails or have explicitly extracted it from the service provider, and intend to commit to that service provider. For example, a contractor would be ecstatic if he/she could post an ad for a set of pricing tiers for kitchen remodeling based on kitchen size and style, provide evidence regarding quality of service and accept signed contracts from consumers who were looking for kitchen remodeling. Furthermore, if it was common knowledge that kitchen remodeling required that the customer gets involved to a certain level of depth (picking out appliances), no one would have issue with the implementation phase since it was expected and generally accepted as protocol.

Notice how I hedged with the wording “as is common.” Frequently, product and service providers feel that their customers are a completely naïve group that lack the necessary crystalline knowledge and fluid intelligence to comprehend what they offer. Usually what this means is that your product or service has not been distilled to the correct level and cannot be digested by prospective customers without your help.

I bump into lots of folks in my SaaS discussions and travels, and I frequently hear “well, we’re not really worrying about self provisioning at this point. Our offering is too complex anyway.” What seems to be the case in most of these situations is that the SaaS provider has not identified a clear separation between engagement and implementation. In most cases (there are a few exceptions) engagement is not a complex process, even if implementation is. Without a clear distinction however, the complexities of implementation bleed into engagement, giving the service provider a false signal. In the SaaS business, a customer engages with a service by discovering the service and committing to use it. One can commit to use the service (signing a contract, paying some money) without being able to necessarily use the full functional set of the service immediately (since they may need complex implementation). Provisioning is just a synonym for pursuing and following engagement through to the end. If you’ve clearly separated engagement from implementation in your application and workflows, I’d say there is little reason to not allow self-provisioning. With SaaSGrid, we built a system that could take any application and provide an out of the box “storefront” and self provisioning capability because of this belief. You want to leverage point in time emotions your prospects have. When a prospect browses your corporate site, and they think “Hey, I really think this is the right system for us,” to lose that positive momentum because you didn’t think about or build a self-provisioning system would be a terrible loss. Do you have a complex implementation that would require the customer to migrate data, go through specific tailoring and setup? Fine. Do it after they engaged and committed to your service.

Do you agree that nearly all SaaS offerings, if cleanly partitioned into engagement and provisioning pieces, should offer self-provisioning? Do you see significant advantages to not offering a self-provisioning model?

It’s important to first understand where the term “cloud” originated, as it should really be used in a constructive approach to arriving at the definition of “private cloud” and the determination of how accurate of a term it really is. The term “cloud” originates from a scary place: network diagrams. Have you ever used Visio or a similar tool for modeling diagrams? If so, and if you’ve ever created diagrams that required some sort abstract network, you’ve undoubtedly used the “cloud icon” (which looks kind of like the dust-balls that the Road Runner would leave behind when being chased by Wiley Coyote). This icon was used to denote an abstract network at some responsibility boundary.

Ok, so the history of the term cloud is somewhat rooted in telephony, but we definitely adopted the icon for broader use in general network diagrams. Point being, the origins of the term “cloud”" had nothing to do with the public Internet, and I’d argue it still doesn’t. A cloud is simply an abstraction of network and resource responsibilities that one can leverage in support of some other functional tier or silo. The network diagrams that we’ve all created never restricted the use of the icon to the Internet, but rather remained open to use in any situation where you had to clump non-specific, potentially unidentifiable (but conceptually understood) resources into a dependency.

Given the history of the term and its typical usage, what makes the term “private cloud” so broken? Nothing. An enterprise can use Internet architectures to create internal, “private” resource abstractions. These are private clouds that can be used in a variety of capacities. Granted, larger enterprises are better positioned to leverage private clouds, but that doesn’t mean smaller enterprises won’t build them as well.

All this said, I do distinguish the Cloud, as a proper noun, from a general cloud. The proper noun Cloud should be used to identify the public internet.

How do you feel about the term private cloud? Does history not matter when it comes to best understanding the term? Let me know!