Wat is de impact van PaaS op APM?

In theorie, aangezien PaaS-applicaties kunnen worden gebouwd met behulp van gemeenschappelijke standaarden en tools, zou het hetzelfde moeten zijn voor het bouwen van mogelijkheden om die applicaties te bewaken. Met minder maatwerk zou het monitoren eenvoudiger moeten zijn, toch? Welnu, als de inhoud van het artikel, "Studie:PaaS Market to Top $ 6,94B in 2018", geschreven door Chris Talbot in Talkin' Cloud klopt, bedrijven zouden eigenlijk nauwkeurig willen beoordelen of hun APM-tools in een PaaS-omgeving zullen slagen. Dit is waarom:

1. PaaS-platforms zijn meestal gespecialiseerd in een bepaalde programmeertaal, dus als een APM-oplossing die taal niet controleert, kan het niemand binnen die PaaS-omgeving helpen. Als de ondersteuning niet zo goed is als die van een concurrent, zullen ze echt niet in staat zijn om binnen die omgeving te concurreren, zelfs als ze het integratiewerk doen. Als een APM-oplossing die taal echter wel ondersteunt, en goed ondersteunt, zal elk inzicht dat het toevoegt en specifiek is voor die PaaS-omgeving uiterst nuttig zijn.

2. PaaS-platforms hebben veel abstracties en verborgen lagen, dus er zijn gebieden in die omgevingen waarin een monitoringoplossing geen inzicht kan krijgen:

• Routing: Het routesysteem van Heroku is een van die gebieden, maar het is erg belangrijk om de prestaties ervan te controleren, zoals geïllustreerd in het artikel Taming of the Queue.

• Machineconfiguratie: Een ander gebied dat een APM-oplossing mogelijk niet kan controleren, is de configuratie van bestandssynchronisatie omdat deze geen volledige toegang tot de machine kan krijgen. Het heeft misschien toegang tot de programmeertaal die erin draait, maar het heeft geen toegang tot alles wat er op de servers gebeurt.

• Eigen extensies: Een PaaS-omgeving kan componenten bevatten die eigendom zijn:aangepaste versies van de server en aangepaste extensies voor een taal. Er is enige geheimhouding met PaaS-providers met betrekking tot hun componenten, omdat ze op die manier in staat zijn om die omgeving uit te schalen en zich geen zorgen te maken over concurrenten. Daarom kan een APM-leverancier die componenten niet controleren, tenzij hij kan werken met de PaaS-provider.

• Diensten voor meerdere huurders: Veel PaaS-omgevingen bevatten gedeelde services, wat een probleem kan zijn voor bepaalde soorten monitoringtools. Multi-tenant database-instances komen vrij vaak voor. Als de agent van de monitoringtool met de database moet praten om er gegevens uit te halen en deze multi-tenant is, heeft de tool mogelijk niet de toegang om dat te doen. Als het geen andere manier heeft om die database-informatie in die PaaS-omgeving te krijgen, zal het nooit databasestatistieken kunnen leveren.

• Externe diensten: Een PaaS-omgeving heeft ook de neiging om een ​​aantal externe API's te gebruiken, een ander gebied waarop een monitoringtool gegevens kan missen. Ontwikkelaars kiezen voor PaaS omdat het handig is, en ze wenden zich tot een API omdat de servers en de PaaS meestal kleiner en minder krachtig zijn - het is een goede manier om het werk van hen te ontlasten. Als een APM-oplossing niet de mogelijkheid heeft om API's te bewaken, of als het vermogen niet erg sterk is, dan wordt dat een zwak punt in een PaaS-omgeving.

De zaak voor het bewaken van uw PaaS

Er is een overtuigend argument voor interne monitoring als u bovenop een PaaS werkt. Elk van de afzonderlijke services op de PaaS wordt gebouwd en geschaald door het platform, maar de applicatie zelf is niet hun verantwoordelijkheid. Het maakt niet uit hoeveel je standaardiseert, er zullen altijd prestatieproblemen zijn die je moet controleren en je hebt een tool nodig om dat te doen.

PaaS-aanbieders hebben ook hun eigen complexiteit, intern. Ze zullen meerdere services hebben:een accountsysteem en een web-GUI voor het factureren van de PaaS, een ander web-GUI-systeem om geconfigureerde add-ons te beheren en een service om de configuratie op de PaaS-servers te beheren. Zelfs als de servers draaien, als er geen nieuwe configuratie-instellingen naar hen kunnen worden gepusht, zal de service degraderen. Het bedrijf kan zelfs een service gebruiken om toegang te krijgen tot zijn prestatiegegevens. Er zijn veel services in het PaaS-ecosysteem waarvan het zinvol is om ze te bewaken, dus er is de interne use case om alle servers draaiende te houden, maar ook om alle infrastructuuronderdelen te optimaliseren die de PaaS zo gebruiksvriendelijk maken.

Volgende generatie PaaS

Vooruitkijkend is de trend geweest dat PaaS-servers steeds kleiner worden, maar je moet al die servers wel in de gaten houden. Als de monitoringtool van uw bedrijf niet gericht is op het ondersteunen van veel kleine omgevingen, kan het minder kosteneffectief zijn of schaalproblemen vertonen. Bovendien zijn individuele servers veel vluchtiger dan vroeger. Ze bestaan ​​misschien maar uren of zelfs minder dan een uur in plaats van dagen zoals ze ooit deden. Als gevolg hiervan, als uw monitoringtool is gericht op het idee van een server die al lang bestaat, kunt u mogelijk niet zo goed omgaan met een omgeving waarin servers gewoon verdwijnen en weer verschijnen zonder dat iemand dat ooit expliciet zegt.

Het maakt niet uit hoe je het opdeelt, elke applicatie evolueert voortdurend en vereist een zorgvuldige planning om effectief te schalen. PaaS-providers kunnen helpen, maar dat betekent niet dat monitoring geen plaats heeft.